On Proactivity

IT does a ton of work to support a company.  We make sure billing systems accurately charge clients.  We make sure our HR systems pay everyone properly, and we make sure our websites are up and accurate.  All of these things are incredibly complex challenges that require a great deal of expertise and skills to manage successfully.  Despite of all this work, however, IT is generally perceived as a reactive function; we just sit around waiting until someone reports a problem to us.

Certainly some part of our function is reactive… we do, after all, have a help desk and support portal to solicit tickets.  There will always be some portion of our work that is reactive, we cannot, after all, be everywhere at once.  There will always be SOME challenge that pops up in an area we don’t have eyes on.  Just because a small percentage of our work necessitates reactivity, we shouldn’t accept only being reactive.. Indeed, there is a LOT to gain from doing the opposite, from being proactive.

---

Being proactive means a number of different things in tech.  Most importantly it means letting others know that something is going on.  Being in IT means we get an advanced view of how the systems are operating.  We get dashboards, alerts and reports that most folks don’t get… and even if they DID get them they wouldn’t necessarily understand what they mean.  This makes proactive communication the single most important thing we can do to increase out impact.

I take this lesson to heart and make alerting folks one of the first things I do when I find a problem.  (The only step I would take before this would be to stop the immediate bleeding to help minimize the impact of the problem).  This have a number of advantages:

• Get ahead of the problem - Letting folks know about a problem before they find it helps prevent the wave of “OMG XYZ thing broke, help!” emails/calls/slacks/visits/telepathic messages that will come once folks realize there’s a problem.  Your email just saved god knows how many tickets.

• Builds partnerships - This is an important one!  By showing your partners that you’re actively watching out for them you build trust.

• Rallies the troops - Proactive alerts also let’s your team know that somethings happening.  This gets more eyes on the problem, and helps solve the challenge more quickly.  It can also help tap into other teams sooner since they’re now aware of the issue.

---

The good news about being proactive is it doesn’t take much effort… a few sentences describing what you discovered and that you’re looking into it goes a LONG way to avoiding an escalation.

Domain Expertise

In the tech world we tend to focus on learning the tech.  Those of us working on any given system or tool want to drill into how it operates, what features it has and when they should be used.  This is true for NetSuite, or AWS, or InfoSec.  And there’s nothing wrong with making technical skills a focus of our job; after all we ARE the systems folks!  

Learning technical skills, however, shouldn’t (can’t!) be all we focus on.  We also need to stretch ourselves to understand the domain our systems exists in.  For SalesForce this would involve learning how sales teams operate.  What does any given Sales rep need to do or know on a monthly/week/daily/hourly basis?  Why do they (dis)like any particular aspect of SalesForce?  What policies does the Sales team have to follow?

While certainly not directly related to the system, questions like this help inform WHY and HOW the system can be used.  We don’t need to know as much as our customers about their process, but the more we know, the better we’ll be able to support them (personally I became a license health care broker to help accomplish this).  

Gaining Domain Experience

There’s many ways to help expand our domain expertise.  The simplest is simply through osmosis.  As we work on any given system, we’ll naturally learn a bit about the domain it exists in.  Working in NetSuite, for example, will expose us to charts of accounts.  SalesForce will expose us to a closing process.  Workday will expose us to hiring.  This is a natural first step for many folks since it’s basically impossible to miss; you can’t learn the system without picking up SOMETHING.  That said, this is only the beginning.

Getting to know your customers is another way to improve your domain knowledge.  Get them involved in testing, or have them show you how they use any particular screen.  Sit in on their team meetings and get a feel for how the team behaves.  This first-hand experience has several advantages, including giving you more domain expertise, but also helps build connections and puts a face to everyone.  Knowing Jimmy in sales is much more impactful than knowing some random user has problems.

---

Training like your customer-base takes this a step further.  Go and get whatever certification or accreditation they need (like my example of becoming a certified benefits broker).  This will not only extend your baseline knowledge of that particular area, it will help you see things the way they do.  In the care of a credential or training you’re also rounding out your own experience and possible exposing you to new concepts.  This has the added benefit of (generally) getting you some street-cred with your customers.

Going even deeper you could even BECOME your customer.  I very rarely see folks taking this path since it is very intense and time consuming… but it does offer the most in-depth way to gain experience.  For example a software engineer might choose to implement a live customer, or a Salesforce rep may take some inbound calls.  While this does crank up the intensity a bit, it will really help show you what’s important, or annoying, or impactful for your customer base.

While there’s nothing wrong with not taking these steps, I find they help individuals make better informed decisions and allows them to develop better solutions to challenges.  Flexing ourselves this way also has the side-effect of helping us build better relationships, and learn something new about our tool.

Skill Shapes

Everyone is different (citation needed).  This part of our reality impacts every aspect of our interaction with folks, but in this particular piece we’ll look at how it impacts our work.  There are many different ways to try and quantify or qualify our differences, from things like MBTI personality assessments, to background degrees, to more.  Here, we’ll focus on our skillsets, and how our understanding of others (And our own) can impact our work.

One straightforward way to look at skill sets is to group them into “T”, “I” and “Broken Combs”.  These three classifications are useful to understand where an individual’s strengths lie, and how they can be best utilized to tackle any given challenge.  They can also be used to dig into past projects or events to better understand why things went the way they did.  I’ll start with a high-level of each of these, then dig into them more in the coming weeks.  Note that none of these is necessarily better or worse than any other - they’re just tools to help understand people a bit better (yourself included!).

Skill Shapes

I-shaped people

I (like the capital I or lowercase l) shaped people tend to have one deep skillset… and not much else.  These individuals are valuable where in-depth knowledge is needed for a particular area - specific programming languages or systems, business processes etc.  In my experience I-shaped people tend to be a bit more senior in their career or area, and likely ended up choosing to focus on a particular skillset because they find it interesting, or have a particular talent for it.  Note that this extreme specialization can make it challenging for them to adopt new concepts/ideas, which may lead to blind spots developing.

T-shaped people

T-shaped individuals are similar to I-shapes, in that they have one specific skill they’re much better at (the vertical line in the “T”), however, they also possess at least a passing familiarity with several other skills (the vertical line in the “T”).  This broader exposure of skills allows them to more easily flex between assignments, or to more easily interface with other groups as they may know some background concepts or parts of their systems.  Note that because they also possess a broader skillset, their in-depth knowledge may not be as deep as someone who is “I” shaped.

Broken Combs

Like T-shaped people, broken combs possess basic knowledge in a broad set of skills.  They differ from T-shaped people because they will possess at least 2 skills in more depth (this is where that name comes from… imagine breaking most of the teeth out of a comb).  This allows them to be subject matter experts in several areas, while still maintaining general knowledge of others.  Similar to a T-shape, however, their depth of knowledge in those areas may not be as great an I shaped person.

Each of these shapes offers its own insights, and I will be delving into each of these shapes over the next few weeks. Like many concepts these are not intended to limit or restrict an individual… instead they’re intended to be used to better understand how an individual or team will act (or to explain how it got to a specific situation).

Bring Solutions

“Don’t bring your manager problems. Bring them solutions.”

We’ve all been in situations where we’ve found something that needs to be done/fixed/corrected/etc.  Our kneejerk response to finding these things is to point them out, to tell our manager/coworker/spouse that we found a problem.  This isn’t a bad thing... After all, we’re flagging a problem for others, and that’s the second step to getting it solved (number one being identifying there’s something wrong at all).  Indeed, many folks don’t even take the first step of identifying things that need fixing, which itself is a fascinating topic.

---

The weakness with this approach however, is it’s passive.  We’re telling everyone “Hey, I found something broken”, and nothing else.  There is certainly value in this, since now others are aware of the thing, however, you’re basically just making work for other people.  Now that it’s a known problem, your manager/team/parents/whoever, need to figure out what to do about it.  Suddenly someone else now has move work on their plate… work that you basically gave to them.

Bringing solutions

Instead of pointing at a thing and saying it’s broken, instead point out how you’re going to fix the problem.  For example, instead of “We scheduled the wrong flights for our vacation”, try something like “I noticed our flights were for the wrong dates, I’ve already emailed the airline to get them changed”.  Or how about instead of “All of these new hire records have the wrong hiring manager”, try “I’ve found that 54 new hires have the wrong hiring manager, here’s a list of their correct ones that I’d like to update”.

I always try to think through what I would like to get if the problem was brought to my attention and work backwards from there before I send out any communication.  Is there background info I should be including?  Are there statistics or other numbers that would be helpful (e.g. the total number of errors, people impacted, etc)?  Are there other folks that should be informed or brought into the discussion?  These questions help me shape what I pass along, and help shorten the time from “see thing broken” to “thing is fixed”.

What’s in it for you

This approach lets others know about the danger, and also demonstrates you’ve thought it through and have a fix in place.  You’re both saving them time by presenting a fix, and also demonstrating your initiative/skill/etc in fixing it.  By presenting both at once you’re also giving them an opportunity to weigh in… maybe they have a different fix in mind, or some new approach they could teach you. Regardless, you’ll end up in a more positive spot overall… either having solved the problem yourself, or gaining something valuable as a result.

No Extra

Extra, in some cases, is good.  Extra guac? Please.  Extra time to sleep in? Sure.  Unfortunately on a project, extra can be bad.  At best adding extra to things distorts our view of the request and makes it easy to lose sight of what is actually needed.  At worst it totally derails a project and diminishes its value to your customer.

Adding extra into our work does several things… some obvious, others much less so.  I find that instead of making things better or providing a better output, these additions detract from my deliverable.  Here’s several ways how:

Energy drain

Working on extra stuff that is “better” than our objective distracts us from what we should be doing.   We can tell ourselves we’re helping, or that we can make up the time, or that the actual request is easy to do, we’re just making it harder to complete our objective.  At best we end up putting less energy into our objective, which results in risk that we missed something important, or that the product isn’t as strong as it could be.

Diffused Focus

Working on extra necessarily pulls our focus away from what we should be doing.  Instead of critically examining our request for potential flaws, we’re day-dreaming about something unrelated.  This split focus allows us to make mistakes we otherwise would catch.  Even worse, this can result in less time to figure out the “extra” we thought was so valuable… so instead of delivering what was asked we deliver one thing that was asked that may or may not work, and another thing that wasn’t asked for of questionable use.

Missed Target

Working isn’t done in a vacuum, and we as individuals (and sometimes teams) can’t know everything.  When we make a choice to add extra to a request we’re gambling that we know what’s “best” or “right”.  While we might get lucky and deliver something that is, in fact, useful or valuable, what happens if we’re wrong?  Suddenly we have to explain why we wasted time NOT working on what someone wanted to build something that’s useless.

---

I find it fascinating how hard it is to only do what is asked, and nothing more.  It should be an incredibly easy thing to do, but the allure of making it “better” is very hard to resist.  As funny as is it to say, it takes discipline to stay inside the lines.  It is true there will be times when we can push on those lines, and sometimes help redraw them, we need to be very careful not to wander outside them.  Doing so distracts us from our objective, and instead of building us up, only tears us down.

Standards

Standards exist in every discipline.  Effective Dates in Workday, Boolean logic in systems, federal regulation in hiring and the color wheel in art are all examples of Standards.  It is certainly possible to get by NOT knowing them, having these tools available on demand makes getting things done significantly easier.  Not only that, it makes working with others in your field easier as well.  A shared vocabulary and understanding enhances collaboration by allowing teams to quickly share information.

---

Martial arts are a great example of a group that uses standards.  Generally these are sets of movements or ideas that you need to learn in order to progress.  As a newer student these standards serve as the next hurdle towards rank advancement and as a literal standard everyone your relative experience and rank needs to know.  As a more advanced rank you realize that these don’t just serve to roughly bucket folks by what they know, they serve as the building blocks towards more interesting things.

Professional connection

Professionally standards are generally learned earlier in our careers.  We go after a bachelors degree to get a solid understanding of fundamentals.  Our first jobs teach us basic skills like problem solving and communication.  Our first year(s) coding are spent learning terminology and concepts.  In many cases standards can be codified and taught in a structured way, for example a course at university.  They can also be taught in an unstructured way, copying an existing piece of art/code/whatever, for example.  The former relies on an instructor to help guide you, which is great since you benefit from their skill and experience.  The latter relies on your own self-exploration, which is great since you learn how to learn.

For me it gets interesting once you know the standards in your field.  In them martial arts, for example, the standard forms are interesting and have a very important place in training… but they’re ‘boring’.  They’re the same… we know them (although I can easily argue you can always learn more from them).  Understanding the underlying lessons in them, and then applying them to something new, now that’s interesting.  The same is true in other areas.  We’ve all written a “for” loop that counts to 10, but getting to apply that idea to a webpage that solves a real problem is MUCH more interesting and satisfying.

---

Unfortunately reality is a bit grittier; the group you work with my not have the same set of standards.  While this provides an advantage in terms of differences of opinion and skillsets, time and energy can be lost if part of the group relies on standards that, well, aren’t standard.

I find that a lot of groups need up-front time spent agreeing on what the standards are (or even understanding they exist).  This shifts the focus from “lets go build something cool with our collective background knowledge” to “lets agree on what the tools are”.  This can easily feel like a delay in getting to the work at hand, but it is time very well spent.  The start of a project should include time to level set on standards including what specific terms mean, what methodologies or tools will be used and how to communicate.  This will reduce the change of a misunderstanding as to standards and free up time to innovate.

At the end of it all standards are just that.  Standard.  Knowing that something will be the same, regardless of where you happen to be or who you work with, is incredibly powerful.  This common language allows you to look into new topics, and explore old ones in new ways.  They also serve as a fallback, something you can use and rely on when things get pear-shaped.  The trick is to share your standards with others, and to be on the lookout for opportunities to apply them in new and creative ways.

Laid Off? Invest in Your Self

I can now claim the dubious honor of being caught up in two different layoffs at two different startups (one more for the hat trick!). Both times I have been part of a much larger group that was laid off due to dramatic reorganizations that impacted the entire company, and while they were certainly traumatic to some extent, I have viewed both as an uncommon opportunity, as space in which to improve my Self.

---

Growth Takes Space

I’ve found that when I’m working at any particular job it can be hard to think of next steps.  The mental weight of having that job makes it harder to envision a better / brighter / whatever path.  This “old growth” makes it harder to see what a next step could be, or to see what I would like to improve.  After all, I already have a job, so why would I look for something else that might be a better fit for me?

Having now been laid off twice in my career I’ve found it has a similar effect on my mental state; a (relatively) brief period of trauma followed by more room to expand with new ideas and directions.  I also feel this on a much smaller scale when I get to work on a new project or have a new position… space is created by giving up something old, which allows something new to grow in its place.  The challenge I have is to guide that growth so it serves me, instead of just growing organically.

---

Uncertain Direction

One of the challenges with getting laid off is it strips away some of our direction.  We no longer have a job to report to, no longer have teammates to whiteboard solutions with, no longer have systems to monitor or memes to send out.  This opens up a wide range of possibilities, but also introduces some uncertainty into what we should do.

This raises questions which lead to more questions which lead to more stress:

• “Why me?….”

• “What did I do wrong to end up here?”

• “How will I make rent in X months?”

• “Who’s hiring?”

• “What will happen to the plant I left at the office?”

While concern is warranted, worry is not a good strategy (it’s right up there with hope).  Instead of focusing on that concern, I’ve begun to view this uncertainty as a freedom (although usually not without a period of freaking out a bit…).  This is really a nice clearing to sit in comfortably for a little while, a space to help me ask slightly different questions:

• “What should I keep doing wherever I end up?”

• “What should I stop doing when I get there?”

• “What do I WANT to do?”

• “How can I do that?”

This shift in mental direction makes it easier for me to be on the lookout for opportunities that I will find of value and provide some personal growth (this blog for example).  By shifting the internal discussion from “this is only terrible” to “hmm, this is a great opportunity” I find it much easier to find new paths forward, paths that maybe I wouldn’t have seen earlier.

I’m not saying this is necessarily easy, especially as other circumstances can add further pressure (having a partner who is also out of work, children to care for, etc).  We certainly need to keep the totality of our lives in mind, but taking the time given to me by getting laid off and investing it in myself has given great results.

Time to Breathe

The space provided by being laid off generally results in some period of not-working-time.  Not-working-time is uncommon in our adult lives… we may take a week or two vacation, but rarely will get more than two weeks in a row where we’re not required to show up from 9-5 (or 8-6… or 7-7…etc).  After the initial shock wears off, this time can be spent to just…breathe.  Take stock of what you’ve got going on, cultivate your self and enjoy the time you’re not slaved to a clock to finish a project or answer tickets or follow up on some report.

Some folks take this time to travel in ways they couldn’t before (Tahiti for a month?), others use it to get into a hobby they’ve always wanted to (cross-stitch anyone?).  I’ve personally used it to meditate and better understand my self (honestly one of the most challenging, demanding, and rewarding exercises I’ve ever done).  The point isn’t to do a specific thing, but instead to not just focus 1,000% on finding the next job.  Instead use this time to step back, take a breath, and think about how we can create the life we want vs. accepting the one given to us.

---

Seeing the Clearing in the Trees

Getting laid off is an incredibly stressful event, and it can be incredibly challenging to find the bright spot in losing your job.  While it’s true this is work, and may take a lot of mental energy, it is an incredibly rewarding way to spend this time between jobs.  Some ways I’ve found to help see the space and appreciate it:

• Question yourself - Ask questions to yourself about what you want to learn or do differently with your career and life instead of just how to keep it moving along the same path.

• Chat it up - Talk to friends and family about what they know about you… what they think you’d enjoy doing, or what you’ve enjoyed in the past.  Their perspective is incredibly valuable and can give you great insight into your blind spots.  Talk to (now former) coworkers about what you did well and pursue that.

• Just chill - Take time to indulge a bit more in things you enjoy.  Take a painting class, go somewhere you’ve always wanted to but “couldn’t”, workout.  This rare bit of time if yours to shape into whatever you want.

Short Bite - Get it done

Backing up entire systems is a very data-intensive process.  Not only does it involve moving a ton of data, it requires specific timing in terms of jobs, processes and systems to ensure it is done correctly.  Even with dedicated data lines, this process can take hours, or sometimes days, which in general is OK. I, however, found myself in a situation where we had to get a copy of our database from Seattle to Portland by 8am the next day.. And it was already 4pm.

---

The Problem

We had two data centers that mirrored each other, one in Portland, and another in Seattle. This is a common setup for data centers since it allows for fault tolerance in case one goes offline, and can help provide faster speeds depending on which one you’re closer to.  We had just completed a big update in Seattle data center, and needed that update to also be made in Portland. These updates were critical to the success of the project, and due to some (I’m sure very important) technical reasons both data centers had to be up to date.  One option was to do this “over the wire”, that is copy/paste the information over the internet. This was the simplest method, however, also the most time-intensive.  This was an incredibly large update, and despite having a dedicated line between our data centers estimates ranged from 12-48 hours to complete the update. Unfortunately this delay would break out deployment schedule.

---

The Solution

Someone pointed out that driving from Portland to Seattle only took about (a very boring) 3 hours, which was a LOT faster than going over the wire.  We hatched a plan to copy the updates to a laptop, drive them down to Portland and perform the update overnight. (Despite advances in wifi and internet speeds using the “sneaker net”, or physically walking data from point A to point B is still the fastest way to move data).

Wanting to ensure others on the team could focus on their work (and also to maybe get some quality alone time), I volunteered to be the courier.  After quickly downloading some new music I was handed a laptop and a list of commands to run when I got to the Portland datacenter.  After a (very boring) 3 hour drive (Protip : bring more than 2 CDs), I plugged into the Portland datacenter and took a nap while the updates ran.

A few hours, and one massive update later, I drove back to Seattle.. Where I promptly crashed in my hotel room for a few hours.

---

The Takeaway

Ideally projects do not present situations where extreme solutions like driving all throughout the night are needed.  Ideally.

When those situations are encountered, however, it’s always a good idea to get the team together to brainstorm.  See what possible solutions you can come up with (no matter how insane they sound), and then pare them down to what’s possible given your requirements.  In this case, we HAD to have the update live the next day, so that ruled out some options. It was also possible to safely use the sneaker net to make the update happen (e.g. I didn’t have to break all the speed limits).

Plus, sometimes you’ll get a great story out of it.

Performance Reviews!

It’s that wonderful time of year when employees the world over receive their performance reviews and the collective blood pressure/stress levels spike.  Performance reviews always feel like a stressful situation, for both managers (who have to find ways to constructively point out areas of improvement) and employees (who have to find ways to accept feedback in a healthy way).  I find it very helpful to keep one thing in mind - people wouldn’t give us feedback if they didn’t care about us.

---

Asking for Help

I know I’ve agonized over every step of the feedback process, from selecting peers to provide it, to writing my own, to reading my own.  It can be very hard to get into the mindset of “I want you to help me improve” because it requires us to become vulnerable. Not only are we asking for help (something in itself that can be a challenge), we’re asking for someone else to hold up a mirror and show us the flaws that we don’t see.  

Despite the pain, this tends to be the quickest way to figure out where you can improve.  If you’re looking for a promotion, you’ll certainly need to do this, but at the very least you should be interested in making your life (and your coworkers lives) easier by plugging the holes and amplifying your strengths. The point of feedback is to improve yourself. Unfortunately many of us confuse it with getting a promotion/raise/etc, which corrupts the goal and dilutes the result.

My approach is to pick somewhere from 5-10 folks to provide a review.  I know some percentage won’t get back to me, so having 5-10 helps ensure at least a few will (this doesn’t include my manager or direct reports, who are generally automatically included).  If I can’t think of folks I go over any projects I’ve worked on over the year (also helpful with writing your own feedback!), specifically for longer or more challenging ones and select folks from those.  I also do my best not to cherry pick only folks I know will give me a “good” review… the intention is, after all, to improve.

---

Writing Your Own Feedback

This to me is always a challenge.  It requires both cheer-leading yourself but also being objective.  You need to keep enough self-awareness to point out where you can improve, while also showcasing your accomplishments.  It also requires actually remembering what you’ve been up to.

I start with just listing out things I’ve done over the year (or however long it’s been since the last review) and grouping them into themes (led X# projects to completion, etc.).  I may call out one or two big wins, but this is mainly to help me shape the rest of the my self-review. Once I’ve got a good view of what went on I see if there are any patterns (positive or negative) to look into.  These patterns make it much easier to start, and also provide a focus as I think through what I’m going to write down.

The critical self-feedback is always a bit more challenging, but I perform the same basic process - examine my work for any patterns I want to change, and dig into those.  This may result in bigger themes (e.g. improve my ability to think strategically) to specific skill sets to improve (training in project management).

---

Writing Others Feedback

This one is always a toss up for me.  Not a toss up in terms of “will I do it?”, but in terms of what feedback I’ll give them.  The general intention I follow is to call out things they do well and should keep doing, and point out areas they may either be unaware of, or areas I feel they can be stronger.

Blind spots can be tricky to point out since I don’t want them to feel attacked.  For example, “You never provide a meeting agenda and I hate that” isn’t really a positive way to point out an area to improve.  Something more along the lines of “You schedule a lot of meetings, I think you’d be more impact by including an agenda”.

Point out areas to amplify is a bit easier, since you can build on something they already do.  For example “You’re off to a great start writing project summaries. They’ll be even better if you include an appendix”.  This not only shows them a behavior you want them to continue to do, but offers some way to make it even better.

---

Positives and Needs Improvement (Work in Progress, Weaknesses, Opportunities, etc …)

One of the major features of a performance review is to include examples of your strengths and weaknesses.  This is always a fun exercise of first remembering what you’ve done over the past 6-12 months, and second critically thinking about areas you can improve (which tends to run directly into my ego at full speed).

I find it easier to think in terms of stories when talking about strengths.  Saying you’re a good communicator is one thing, but providing a narrative that gives context and details makes it both easier to write and share.  Conversely I find it easier to stick with discreet statements on opportunities, and then add a bit about how I will improve it. This helps demonstrate that I both understand where I need to improve, and have thought through some fixes (at the very least).

Strength example - My communication skills helped defuse a very tense escalation with a client resulting from a system error.

Weakness example - My communication skills need work.  To improve these I will sign up for XYZ class and double check every email before sending.

The goal here is to exercise self-awareness so you can self-correct. Feedback from others twice a year is good, continuous (honest) feedback from yourself is even better.

---

Dealing with feedback

Opening yourself up to feedback can be a very scary (and challenging) thing, and getting it can be even more challenging.  I tend to read my feedback several times before I even try to understand it. This mainly stems from reading the “opportunities” section (e.g. where you can improve).  My ego frequently kicks in and gets defensive about the comments and immediately begins formulating responses.

Not very helpful.

It’s not helpful because this individual is:

• Someone I’ve asked to help me by giving feedback - While not true for 100% of folks (e.g. some places may assign reviewers, and typically your manager and direct reports always give feedback), in most cases you’ve ASKED for their input.  Unless that feedback is wildly out of line you’re both wasting their time and second-guessing yourself.

• Has a unique perspective on me - This is both frustrating and helpful.  Frustrating because you know you don’t do XYZ thing all the time… helpful because it is how at least one person views you (imagine all the folks you didn’t ask who have the same viewpoint….).

In order to actually learn from that type of feedback I desensitize myself to it.  I’ll read it a few times, then walk away. Then come back and repeat. Once the twitching has stopped (for the most part anyway), I’ll then see if I agree with what they said.  Frequently I can find other examples of their feedback, which makes it easier for me to digest it.

I would almost prefer the feedback where my ego kicks in and immediately starts screaming challenges to the feedback that doesn’t tell me anything interesting.  In the first case I have to learn to take a critical look at myself and examine potential flaws (even if I’m blind to them). In the second case, I get comments like this :

“I cannot think of anything else he can improve on”

Possible reasons for this response:

• This is my fault - I may have picked a non-optimal reviewer (e.g. someone who didn’t work with me enough to get a good picture), or I failed to outline what I was looking for in the feedback (e.g. prompting).

• This is their fault - It is also possible this individual simply didn’t put energy into this to think through our interactions.  Basically they’re cheating me out of improvements because they’re lazy.  

• I really am perfect. - (unlikely)

---

Summary

Feedback is a skill, and like any skill it gets better with practice.  Don’t wait for the end of the year, half or quarter to solicit feedback from folks.  The more constant, honest feedback you get the faster you’ll be able to improve.

Case Study - Learning a New System

One of my first jobs had me in the role of a project management module expert for a new system we were installing.  This was a big step for me since it got me out of being an IT Helpdesk Tech and into business systems analysis (something I find a lot more interesting).  This project would impact how 2,000+ people did their jobs across 6 locations, but the challenge I had was that I didn’t know much about project management, or this new system….

---

The Setup

This turned out to be a great opportunity to learn both by experience and by training.  Since we were already using a version of this system we had environments available for me to play in, and, even better, we had other folks on my team who were familiar with the system and underlying concepts.  Having both of these isn’t always the case, so I got lucky (sometimes system implementations involve a team entirely new to the system, which makes for one rather steep learning curve) . It was still a lot of work to make time in the system and to get to know everyone, but it really helped improve my learning curve.

---

First Things First

The first thing I did was get access to a sandbox version of the new system so I could play around.  This helped me build up the basics, e.g. where buttons were, what they did, what our current setup looked like.  The other thing I did was get my hands on the manual (a digital copy anyways). This helped inform my wanderings by giving me some underlying context into what those buttons were intended for, as well as background on the architecture and setup of the system.

Manuals can be a great resource, but many systems are incredibly complex, resulting in incredibly large manuals.  My recommendation here would be to focus on specific areas to investigate (e.g. whatever area you’re responsible for) to build up familiarity with them.  Sometimes it is fun to randomly explore, but I find this can lead to areas that you may never use, or end up being more confusing than useful.

In short, hands on gave me the “how do I do X”, while the manual gave me the “what this does and how to do it”.  The last piece, the “why are we doing this?” came later.

---

Baby Steps

Going from zero experience in the system to something more than zero was a bit painful.  Not only did I not know what it COULD do, I didn’t even have the basics. So I put in time (to use a gaming term, I did a lot of grinding).  I tried adding simple things over and over. I read the same page of the manual multiple times and then tried doing those things to see if it really did that (a great way to check your own documentation!).  Eventually I got to a point where I felt like I could open the system without hurting myself, which was good. At this stage, however, I was almost effectively useless to the team. Sure, I knew there were some buttons, and what some screens looked like, but I couldn’t translate that into helping the business solve anything.

This was by far the most challenging aspect of it all.  Why did finance care how the GL is setup? Was it important that we used a specific numerical sequence for project numbers?  Which data field was used to identify the project owner? The questions were endless, and each time I found one answer, more questions popped up.

Not only was I very new with the system, I was almost entirely new with the business and with project management as well.  I needed help.

---

Help!

Luckily for me, my project team contained a representative from most areas of the business (Accounting, Accounts Receivable, Project Management, Purchasing, etc).  This made it fairly easy to find someone to help me understand the basics, and even better, they were on the same project, which made it incredibly easy to connect and get some of their time.  In addition to getting formal background on what everyone did (I have zero background with Finance, for example), I also got to see how they were planning on using the system. This helped me better understand how my area would interact with theirs (e.g. if a purchase order is placed on a project how does that impact inventory?  What about the general ledger? Hours worked?). These learnings helped me further round out my understanding of the system, and more importantly, the “why” behind how it operates.

I also got help from other employees who happened to use the system.  This was another bit of luck as not every implementation I work on has this setup (although you can generally get help from the system vendor).  These folks were able to provide me more background on historic use, which is honestly a bit of a double edged sword. Implementing (or re-implementing) a system is intended to improve operations, not simply continue with the status quo.  Understanding how something works is critical to improving it, however, you must be careful to not simply copy/paste that into the next iteration.

Connecting with other technical folks helped as well. For example, I originally believed reporting was a built-in module of our system.  After a lot of (poor) guess work, I found out it was mainly handled using MS SQL. Data was loaded into our data warehouse by (what I eventually learned) were CRON jobs, after which it could be used by our data analysts.  Being able to sit down and talk with our data engineer and analysts made this process both much shorter and more enjoyable.

---

Leveling Up

Having hands-on access to the system, formalized training (in the form of the manual) and access to experts on the underlying process was immensely helpful.  While each area was incredibly informative on their own, when combined they played off each other giving me more depth of insight than otherwise possible. For example, understanding that the project number for any given project was added to the general ledger code string shed a lot of light on why Finance was involved in the structure of project numbers (don’t worry if that doesn’t really make sense out of context!).

On the more technical side this combination of knowledge helped explain why our project managers were so adamant about knowing when data was available in their reports.  If, for example, we loaded data from the system to our data warehouse at 1am that morning, their reports that day would be a day old. Once I explained this to them they got much less concerned when the number in their report didn’t match the live number in the system.

---

Learning a New System - Lessons Learned

Despite the specifics being unique to the situation, there are a number of lessons that can be pulled out of this experience and generalized to others.  Indeed, I’ve repeated this general pattern many times so far (hands on, make friends, do your homework) since then.

• Get hands on - learn by doing.  Any time you have the opportunity to get hands-on with the thing you’re expected to learn, take it.  It doesn’t matter if it’s a new programming language, new vehicle or new system, the more time you have poking around and seeing what is where the better.

• Make friends - know your end users.  Get time (face to face if possible) with folks who already use the system, or who understand the underlying concepts that will impact it.  These folks will, at the very least, give you pointers on what to look into next. At best, they’ll be able to walk you through specific scenarios and help answer your questions.

• Do your homework - understand the business applications.  Underlying concepts or ideas are incredibly important to how systems, programs, processes etc. operate.  Take time to read up on your field to get a better grasp of these. While they may be very abstract or seem unimportant they almost always will have an impact on what you do.

Leading vs. Managing

A very common question thrown around is “What is the difference between a leader and a manager?”.  To me, it is very straight forwards - A Leader leads, and Manager manages. Leading or managing are not necessarily good or bad, but understanding the difference is important.

---

Leading

Another term for leading is “to guide”, although a much better one for me is “guide someone along the way”.  In a literal sense this might mean showing someone how to get somewhere in town, although this is only scratching the surface. While physically guiding someone is a great thing, generally in our workplaces leading refers more towards guiding someone towards a goal. This goal could be improving a sales metric, implementing a new system, or welcoming a new team member. The specific instance isn’t important, instead it’s the vision and seeing a path to achieving it that is interesting. Leading is the ability to see an end result, and bring people along the path to get there. Therein lies one of it’s challenges - you have to get people to follow you to that destination. For me, figuring out how to convince others that my goal is worthwhile is part of the fun. Not only does it challenge my view points (and help improve my idea), it helps foster stronger connections with my teammates.

Here leading goes beyond pointing at some distant point and saying “go there” and extends into being part of the journey and solution. Just like giving someone directions to the post office isn’t leading them (you’d have to actually walk with them there) leaders don’t just sit back and give pointers. Leaders are part of the journey to the destination they envision. They share in the successes and challenges with those they lead, and help the group reach the destination together. Frequently it feels like many projects suffer due to a lack of leadership - someone seeing the way forward.

---

Managing

Another term for managing is “to exercise executive, administrative, and supervisory direction”.  This implies that one is placed into this, and that one’s power to do those things is reliant on someone behind a bigger desk.  It would, for example, be very hard to just decide to start managing a team or process at work without your boss (or someone else) making it official (although it would be an interesting exercise in confidence to just walk in and take something over like that).

Frequently we focus on the “supervisory” and “executive” parts of that definition, which makes sense; they’re the most apparent in most jobs. Line workers reports to their supervisors, CEO’s manage their companies. Titles frequently have “Manager” or “Team Lead” in them to indicate some amount of power over subordinates.

Managing doesn’t solely relate to managing people, however, which is where the “administrative” part comes in.  Process managers are individuals who keep an eye on processes and are incredibly important.  These individuals serve as the main point of contact for decisions about a system or process. While they may also manage others, it is not necessary. Executive assistants are another example; they manage their manager’s calendars, schedules and other tasks without directing others.

I’ve always been intrigued by this multiple meaning, and found it very interesting when an individual wants to be a “manager”. They’re very rarely referring to the administrative part, and almost always fixated on the “supervisory” part, likely because it is perceived as the only way to progress or improve in one’s career, something that is incorrect.

---

What’s the difference?

A leader is someone who steps up, points at a destination and goes (with or without followers).  A manager is someone who occupies an official capacity and ensure whatever resources are available are being used properly (be they people, equipment, etc).  It is entirely possible for an individual to be both a leader and a manager at the same time, or just manage, or just lead, or neither. None of these combinations is inherently better or worse than the other, just different. The higher up one goes in an organization, however, the more likely it is they’ll take on a blend of roles. A CEO, for example, must both manager and lead.

Many of us get it stuck in our head that unless we are officially ordained to do something, we can’t/shouldn’t do it. The thinking is that unless someone higher up (your boss, the CEO, whatever) decides to do something, it doesn’t need doing.  This is entirely backwards.  There can only be so many official managers/leaders at any given company.  This means their sight is limited and guarantees they will miss something, or that they simply will not have time to get to everything.  This opens space for leadership to occur at all levels, not just those “official” ones. This allows “non-official” leaders at all levels to step up and, well, lead.

---

At the end of it all

Both managing and leading also be practiced at any scale. There’s always small projects the need leadership (those little things that annoy you, but aren’t “important” enough to make official), and we all manage SOMETHING in our lives (finances, computer use, etc.). The largest difference I have seen is that leading can be done by anyone in almost any circumstance, whereas managing generally has some conditions that need to be in place (e.g. being made a manager). It’s important not to get stuck in a mental trap that the only way forward in your career is to be a manager or leader, and instead focus on the impact you can make.

Certifications vs. Experience

There is a constant debate in the tech landscape (and in many others, I’m sure!) over training/certifications vs. experience.  Certifications, on the one hand, expose folks to a wide range of concepts and ideas, and give a bit of weight to someone as the certifying body says they know enough to be certified.  Experience, on the other hand, is an excellent (if sometimes painful) teacher that provides deep knowledge.

---

The Case For Certifications / Training

Certifications give other folks some indication that you have satisfied the certifying body that you know something. These certifying bodies tend to either be an equipment manufacturer (e.g. CISCO, Google, etc.) or an independent third party (e.g. CompTIA). I find that the harder, more specific skills tend to be manufacturer based (which makes sense since CISCO likely knows the most about their own hardware), while broader, softer skills tend to be third party (e.g. PMI handles project management). Many of these groups have been around for years, and are recognized as industry-standard, which gives the certificates they issues some extra weight.

This makes certifications a great tool to demonstrate your skill set to someone who either doesn’t know you (or your work), and provides a way to validate experience.  Going through the certification process also tends to involve some amount of training and studying, providing more tools and broadening your knowledge base. This, to me, is one of the best aspects since it helps round out knowledge. This both improves my skill set, but also gives me more common ground when working with others in my field.

---

The Case Against Certifications / Training

One of the weaknesses with certifications is the reliance on the certifying body.  You can, for example, buy a doctorate in your field for around $1,000 from an online university.  While you’re technically a doctor, it doesn’t mean you’ve put in the same effort as someone who went through, say, Stanford’s programs.  In a less extreme (and likely more common) case, you may end up earning a certification from a group that isn’t well known, well respected, or is so basic it doesn’t really prove anything (while I love by “Lucid Chart Expert” certification, it only took about 10 minutes to earn and covered bare basics).

A certification’s worth is entirely dependent on what the certifying body puts in the exam, and how others value the certification is dependent on what they think of that governing body.  A Cisco certification, for example, doesn’t mean you know everything about Cisco, just that you have passed the exam (many of which have low barriers to pass, like 60%). This reality makes many people wary of trusting certifications since they only prove that you’ve passed a test, not that you necessarily know the field.  Some groups mitigate this by including experiential requirements in the certification (e.g. the PMP issued by PMI required some number of project management hours verified by your manager). 

---

The Case For Experience

Experience is a great teacher.  I’ve learned a ton about programming simply by trying to solve problems on my own.  The frustration of running into dead ends and the joy of (eventually) overcoming the challenge is a great journey.  As a result, I’ve worked on many interesting problems and expanded my skill set in a number of directions that may not have appeared in official training or certification.  This gives me a deeper background in some areas that I can more easily apply to the next problem that pops up.

The great part is once others see what you can do, they’ll tell others.  Even better, they’ll think of you in the future and send work your way or help recommend you for other roles or projects.  Others having personal knowledge of your experience is an incredible asset that cannot be bought or learned in a test.

---

The Case Against Experience

The flip side is that unless someone knows you personally (or talks to someone who does), they have no idea what your experience actually is or what it is worth.  There’s no way for them to know if you can do what you claim without some kind of validation (e.g. a certification). This is why many companies have a coding challenge component to their hiring process - they need to know if you can walk to the walk.

Experience can also result in you missing key concepts or tools that someone who went through training would know about (a huge problem for me!).  This results in blind spots that may make things hard to figure out since you are missing key information. This is one of the challenges I’ve personally run into learning how to code, although it has led to some great “I could’ve just done THAT this whole time??” moments. At best this helps you learn how to find information (but takes a LONG time), at worst you are unable to continue.

---

My Approach

While I do really enjoy earning certifications (admittedly I enjoy the ego boost, but I also enjoy learning more about what I’m involved with), I do also recognize the value of raw experience.  Over the years I’ve tried to take pieces from both sides of the debate. I’ll use both personal exploration to build experience, and studying/certifications to build general knowledge. This is especially true when I’m given a new piece of tech to work with - I’ll take time to play around with it, while also digging into the general training. I’ve found this approach is great since these approaches compliment each other (the hands-on stuff gives context to the training, and the training guides the hands-on).

One area this has been very useful is in project management.  There are many different concepts/tools/ideas that may be applied, and it’s challenging to get those any way other than training.  Since it’s such a soft skill though, I cannot rely just on the textbooks, I have to get out there and experience it to see what else there is to it.  By having both the hands on experience, and the background concepts I’m able to be a much more effective project manger.

I also find both sides very useful for hard skills, particularly when I was learning Google Apps Scripting (GAS).  I had no background in programming, which meant basically a vertical learning curve. I did learn a lot about programming by experiencing it, but this was best described as smashing my head into the keyboard until it worked, I was missing out on some really basic concepts (data mapping blew my mind… until someone showed me that I was running several nested FOR loops).

---

Parting Thoughts

There’s arguments on both sides, but in the end it is up to each individual’s preference.  This may also be influenced by our working environment (e.g. some jobs may prefer or require specific certifications, many for good reason!  I wouldn’t want to go to a medical doctor that only learned by experience…) Some folks get by great on experience alone, others knock it out of the park with training.  It’s up to each of us to determine the best approach for ourselves, and then to apply ourselves to it.

Tilting at work

Tilting is a term I picked up from playing video games. Imagine you’ve got a team of people playing superheroes and you just lost a game. You make some mistake that loses the game, and then you’re stuck in your head thinking how terribly you are… and then another mistake. And another… and then you’re yelling at your teammates. This is tilting, and it shows up in more places than just video games.

---

Anatomy of a Tilt

I always thought “tilting” was a great term to describe someone on negative run of output. It tends to also go a bit deeper than just venting (but venting can be part of it) and becomes a downward spiral of negativity directed either at oneself (internal tilting) or others (external tilting). I found a great definition from a user named “Kryptine” over on the Blizzard forums (and outcome given the video game context):

As their post suggests tilting may be initiated by something YOU do (for example - in the video game context falling off a cliff and having to start over), or your inability to succeed due to the actions of others (your team member doesn’t pass the ball so you miss a critical play). Regardless of how it begins, the end result is the same - a single spark sets off a downward spiral of negativity resulting in a substantially worse outcome (smashing your computer with a hammer in Kryptine’s case).

All tilts begin with some trigger which kicks off the mental decay. At work this could be missing a deadline, getting poor feedback, etc, but there’s always one specific point that causes it to start. Once it begins, it becomes self-reinforcing, kicking yourself over missing a deadline causes you to get overly critical with a teammate, which causes friction which makes your mood worse. They all also (thankfully) end at some point… generally when you realize things are going from worse to terrible and you just walk away for a bit.

---

Internal Tilting

Most of the time we think of tilting as something we watch other people do, or we do to others (we’ve all had SOME experience doing this). I find that my own self-talk can fall into this category too. Generally this feels like it comes out of nowhere…. “Dummy, you screwed that up the same way last time”, “Well that was incredibly stupid of me”. These tend to be knee-jerk responses to something happening, and I find unlike someone on my team tilting (more on that below), it crops up with some regularity. I’m not sure if this is me being too critical of my own work, or just a runaway internal monolog, but sometimes it is very disruptive.

I’ve found a few ways to help mitigate it’s impact:

• Keep an “I Rock” folder - A stockpile of positive or supportive messages from colleagues / friends is a great way to help those negative voices calm down / go away.

• Ask a colleague for their thoughts - Frequently I find getting an external opinion about my negative thought helps smooth things out. Most of the time I’m either misreading a situation, or or blowing something out of proportion.

• Imagine a stop sign - I’ve been using this one more frequently to stop a runaway train of thought. Just imagine a stop sign (or anything, really) popping up and stopping whatever thought is floating around. You might have to do it several times, but its been reasonably successful for me.

The aftermath of an internal tilt is always a bit challenging… you basically just need to be gentle with yourself and let it go. Take a moment to think about what happened, see if you can identify WHY it happened so you avoid it next time and move on with your day.

---

External Tilting

This is much easier to observe, since you can see / hear someone doing it. This tends to take the shape of a team member being hypercritical, or focusing only on the errors committed. A major difference between this an internal tilting is external tilting can impact multiple people. Imagine you’re in a meeting and someone goes off on you, or in chat, or any other environment that multiple people are in together. Not only will the target of the tilt feel the impact, the rest of your team will as well. An odd advantage of this is that the rest of your team can help to curb or correct the tilt, so the approaches to correcting it look a bit different.

• Point out positive things - This is a bit situation dependent, but when someone is on a negative tear pointing out a win can help get them back on track (or at least nudge them that way).

• Let them vent - Depending on the context, sometimes just letting them vent for a while can burn the tilt out. This can be dangerous since it may put them (or others) into a worse tail-spin, so I tend to reserve this for one on one connections.

• Walk away - This can take the form of you or them walking away for a bit. Simply excuse yourself, get up and leave. Take some time to do anything else to allow yourself (of them) to reset and recenter.

If I’m the one tilting in a meeting II will do my best to call myself out and apologize (usually after the fact). Frequently I will ask my team for help in figuring out what happened and why so we can all avoid it next time. If someone else was tilting, I’ll see if I can identify why and see if I can help avoid that going forward (not always possible, but certainly worth the effort).

---

Tilt Detection and Avoidance

It’s one thing to recognize a tilt in progress and try to disarm it, it’s something else entirely to avoid it completely. Internally I am ruthless with negative thoughts. As soon as I detect one, especially if it’s in reaction to something (like an email that ticks me off) I mentally step back and evaluate what’s going on. Is it possible I’m mis-reading the email? Who can help me fix whatever problem has popped up? Simply taking a few minutes to breath and look at my options helps keep me from spiraling.

External tilts can be a bit harder to manage since we don’t get that same internal feedback, so frequently we can only watch as someone goes off the deep end. The strategy with these is in preparation and knowing your team. Most of us can probably guess what our teammates triggers might be. This makes it relatively easy to determine if/when someone will tilt; just be on the lookout for those triggers. Easier said than done, since it requires you having enough info to make that determination, but it’s certainly possible. When I think someone is beginning to tilt I usually reach out right away with an offer to help. Sometimes it’s accepted, sometimes it isn’t, but simply reaching out can help nudge someone away from the end.

---

Keep it positive

At the end of it all the best way to avoid, or recover from, a tilt is to keep things positive. Focus on the parts of the project/day/whatever that are going well, and help others see that as well. While it can feel a bit like you’re faking it (and you very well might be!), it can nudge everyone towards a less stressful outcome.

Know what to cut

When I was in 5th grade I remember a classmate telling me how excited he was that the teacher was cutting everyone’s lowest quiz score. I got excited because my lowest score was…. low, but I was entirely confused that he was dropping his lowest score, a 92%. To me that was a great grade, so why would he want to not keep it?

Now despite my younger-selfs math-related challenges I find the approach of dropping the things that are holding us back very beneficial. Not only do we better understand what we are doing every day, but we can also hone our skills and improve our outcomes. I’m not suggesting we simply stop answering tickets, or stop doing chores, but I am suggesting that can find creative ways to get rid of the work that holds us back from becoming something greater.

---

What’s holding you back?

The first step is to figure out what, specifically, is keeping you stuck. This might be having to run a specific report, or manage a specific system, or deal with specific client group. I find it helpful to go through my calendar and emails and see what I would procrastinate on, or what I have a poor knee-jerk reaction to. That meeting on Tuesday mornings with auditors that I always dread? That one email from accounting I keep snoozing? Both great examples of things that maybe I could find a way to drop.

Just write down anything that falls into that bucket (I’m focusing mainly on work, but this can apply to anything), and, ideally, a quick reason WHY you’re putting it on The List. You don’t have to make The List all at once (I keep a rolling one going), so don’t feel like you need to cram in everything. The List may also change as time goes on. Maybe the guy in Accounting you don’t like working with leaves, or maybe you’re given the opportunity to improve the report that you hate running. Don’t think of this as being set-in-stone, but rather something that grows and changes with you.

Our example list:

Audit Report

Accounting Meeting

---

Now What?

Once your List is up and running make time to better understand what about each item makes you want to cut it. This could be a one word reminder, or a longer description of why it’s holding you back, but the intention is to better understand both why and how its holding you back. In my math example it would be “A 92 is my lowest score, and it’s lowering my overall grade”. For running a report it might be “The audit report can be run by anyone and it takes 3 hours every week”. Understanding your knee-jerk response to the item will help you better understand what you can do to get rid of it later.

Unless we get REALLY lucky it’s unlikely you’ll be able to get rid of everything on The List, so after you understand WHY it’s bugging you, stack rank everything. I find it helpful to quantify things a big with the following dimensions, both are on a subjective 1-5 scale of 1 being low and 5 being high.

• Frequency - How frequently does this thing come up? Is it a standing weekly meeting, or only once a year?

• Annoyance - How much does this item bug me? Will I complain about it to my spouse daily, or only gripe about it to myself once in a while?

This makes it a bit easier to more “objectively” (in quotes since the scales are entirely subjective) determine which item should be jettisoned before others. Once I’ve rated everything I just add the scores together and look for the highest number.

Our updated list:

Item	Frequency	Annoyance	Total
Audit Report	5	2	7
Accounting Mtg	3	5	8

---

And Then?….

Now comes the tricky part. We’ve done the work of figuring out what we want to get rid of, and in what order… now we have to actually get rid of it. Exactly how this happens depends a lot on your environment, what is available at the time and your company’s culture. Some of my favorites:

Shift the work to a more junior co-worker

“One man’s trash is another man’s treasure”. This can hold true for work as well. Many times a task that I find boring or mundane is something a more junior co-worker will jump on. Instead of being an onerous task I have to deal with, it morphs into a coaching opportunity that helps upskill my team. This is beneficial to me, since I both get rid of the task, beneficial to my teammate who gets exposure to something new, and beneficial to the greater team since skills are being improved overall.

Automate the task

While this doesn’t work in all cases (e.g. meetings), this is one of my favorites. Many tasks, especially those in a tech environment, can be automated away. In addition to getting rid of the work, I find this a fun technical exercise, almost like a mini-project. In the past I’ve done things like automating reports, auto-forwarded emails, written google scripts to automate badging into classes, and tapped into APIs to grab workday data. Any given solution will be unique (which is half the fun), but I really enjoy this approach since I both get to remove work from my plate, and explore new methods of automating stuff.

Delete the work

In some (usually rare) cases, the task can simply be deleted. I’ve found this to be true with some reports, especially ones that are more historic, as well as some access-related tasks (simply stop sending it or remove access and see what happens). You need to be careful with this particular approach, however, since the thing you delete might actually be needed. To help curb this instead of outright deleting something I tend to disable or hide it for a while. If no one notices after a month or two I’ll straight up remove it.

---

I was told there would be no math

While this exercise does take time, it is incredibly helpful, even if you can’t actually get rid of anything immediately. A better understanding of what you want to get rid of will help you start to find ways of improving. You’ll also get a list of things you can talk to your team or manager about, which may lead to some interesting solutions (maybe other folks have the same things on their List, or have creative ways of dealing with it). It helps me to remember that when I’m looking over what I do. At the very least I’ll get a better understanding of my work, at best I’ll be able to better focus on what is really important.

Data Shepherds

Much like sheep wandering the country-side data needs tending. What exactly this entails means a great many things, from ensuring database tables are setup correctly, to running errors checks against incoming data requests, to ensuring proper authentication methods are used. While each given environment may require different specifics, they will require someone to monitor and maintain it. This could be a Database Administrator, Functional Developer, or System Administrator. Regardless of this individuals role or title, they will need some level of access to the data, if only to ensure it’s actually there, and some data, especially things like Financial or PII, can make this a nerve-wrecking experience for partners.

---

And WHY do you need access to that?…

The business side can be understandably nervous when someone has access to their most sensitive information; after all it’s important stuff! What is sensitive may differ based on team, location or industry, but the fact remains that SOME data will fall into this bucket. On the other side is the tech partner who is responsible for maintaining those systems; the individual who needs access as part of their job. Between them lies friction, and responsibility of being a good data shepherd.

There are always times when a technical partner requires access to this sensitive information to perform some Amazing Thing. Naturally (and rightfully so!) the business will question WHY is access required to that information. Frequently my response follows some pattern of

“Without access to your data, we’ll be unable to accomplish that Amazing Thing you wanted.”

— Me

Of course the exact response differs depending on what the data is, but the basic reply is the same. I cannot accomplish the request without access to this data set or system for XYZ reasons. Most of the time (and after some further explanation into the why and how) I’ll get what I need to complete the ask. If pushed, however, I’ll tell them something like:

“Well, it’s possible for me to do this, but without access to the data I cannot validate my solution., which is bad for ABC reasons.”

— Me

This tends to put a stop to any further line of thought, as frequently me (or the team I am on), are the only individuals who can do The Thing. I’m not suggesting we don’t fully justify WHY, or even that we keep access indefinitely, just that calmly pointing out that The Thing isn’t possible without this information tends to be a very good way of convincing a partner to help provide access.

---

It’s just a set of numbers

One of the first times I ran into the challenge of access to sensitive information I was validating Social Security Numbers (SSN) in a HR system. Generally theses are considered to be rather important pieces of information, and so they should be both accurate and highly controlled. Before being granted access a more senior tech taught me a great lesson

“It’s just comparing one number to another, and our job is to ensure they match”

— More Senior Tech

This was very impactful lesson for me and drove home that our job is to ensure the data is correct regardless of what that data is. It doesn’t matter if I’m confirming someone’s email address is valid, and this is especially true when dealing with highly confidential or sensitive information. Commonly this may involve confirming a termination action was correct, or updating compensation. It doesn’t matter that Jimmy makes $5,000,000, all it matters is that particular number is what it should be.

I also frequently let my partners know that once I’m done by access can (should) be revoked. I actually prefer it this way since it greatly reduces the possibility of a problem cropping up. Selfishly it also means there’s one less thing I have to deal with / worry about, which is always good.

---

At the end of the day, most data is important. It doesn’t matter if it’s SSN, payroll data, or publicly available info, it must be tended to appropriately. Fortunately tech partners generally aware of special requirements, but it’s never a bad idea to highlight areas that require more security or specialized handling. I always thank my business partners when they do - it helps them understand I am aware of the important, and helps reinforce our collective responsibility to be good shepherds.

Getting into tech

Many people I speak to who aren’t “in tech” express a desire to be “in tech”. There seems to be a certain glamour surrounding being 'in tech', that being able to say you're 'in tech’ is a Good Thing. I always get a kick out of this since being 'in tech' can mean many thing (also the reason I use the quotes for 'in tech’). Do you want to become a product manager? A programmer? Network Engineer? There’s a huge range of opportunities “in tech”, the trick (after determining you want to make a switch) is to pick which branch you want to look into.

Once you do though, be open to a change of pace/leveling/etc. Depending on your background you may essentially be starting from scratch, so make sure you’re OK with a more junior position than you have now (not saying it’s guaranteed, just be prepared!). Once you’re OK with all that there’s a whole lot more work to do!

---

What do you mean by tech?

When we think of tech most of us tend to think of a programmer locked in her basement making the Next Big Thing. While I feel this stereotype is damaging to programmers (sometimes they’re locked in their bedrooms), it certainly isn’t the only kind of technical role a company requires. Indeed, the types of technical roles available will vary based on industry. Laboratory technicians are likely not needed at a financial firm, and programmers are less likely to be found in factories.

Have an honest discussion with yourself about what you mean when you say you want to get into a technical role. Reach out to folks you know on LinkedIn who you are in a similar field to see what they think, and grab time with trusted friends/mentors/role models to talk through your thoughts. This will help you better target a good role, and, more importantly, better understand where your thoughts are coming from.

To go with the stereotype, if you’re thinking of becoming a Software Engineer (coder), it is a very available skill (throw a digital rock online and you’ll hit a dozen code academies). It still, however, takes time, discipline and a lot of elbow-grease to pick up (especially at any level that will result in a job at a big company). That said, there are many other technical roles available (by no means an exhaustive list!):

---

Technical Project Management

This role blends technical knowledge with project management. Technical Project Managers (TPMs) are essentially project managers for tech. Unlike a “non technical' Project Manager (PM), TPMs tend to require a deeper understanding of the systems or concepts they have manage. For example, a TPM implementing a new SQL database would highly benefit from understanding basic SQL commands, server requirements etc. They also serve as translators between the technical teams and the business partner they’re working with.

Good For - People with project management experience, individuals who want to be around tech without necessarily being IN tech.

Less good for - Wanting to get hands-on with tech. TPMs tend to work tightly with tech teams, but are not generally doing the technical work directly.

Quality Testing

Quality Testers (also called Quality Assurance) are responsible for ensuring products don’t get released with bugs or defects. Frequently this involves developing and executing test plans (which can be incredibly tedious!) that run through every combination of actions or inputs. While they work with software engineering teams they generally do not need the same depth of expertise in coding. They can, however, work on/write testing scripts to help automate the more boring parts of the role.

Good for - Folks who want to get hands-on with tech and do not have an in-depth background

Less good for - Folks who cannot handle monotony. Imagine having to look at the same website for a week and clicking each link repeatedly.

Sales engineering

Sales Engineers work with (you guessed it) sales teams to help sell products. Generally they’re brought in to help demonstrate specific use-cases, features or to find new ways to demonstrate how a product works. Not necessarily a role you’ll find at a smaller company, but larger ones (e..g Salesforce) will certainly have these folks around. Most of the time they know what they’re walking into on a call, but depending on how things go they may have to apply some quick-thinking trouble shooting if an unexpected question comes up.

Good for - Someone with sales experience and interested in working with multiple client groups

Less good for - Someone who doesn’t like sales, or someone or who wants to work with the same customer (internal or otherwise) over longer periods of time.

Data Analyst

Data analysts analyze data (shock!). Contrary to popularly held beliefs there is a huge amount of knowledge needed to be a good Analyst (not just how to use Excel). Fortunately the skills are readily available online and at schools. I personally find this discipline fascinating since it allows us to put order to data and help others draw conclusions from that. Data Analysts almost always need to learn some type of coding language in order to pull and manipulate data (e.g. SQL).

Good for - Someone good at finding and explaining patterns, or good at translating raw data into actionable insights.

Less good for - Folks who don’t like numbers, or folks who don’t like presenting insights to groups.

---

Taking the plunge

Once you’ve got a rough idea of what flavor of tech you’re interested in go learn more about it. See if your company has someone who has that role (or a similar one). Ask your friends if they know anyone who’d be willing to chat about it. Take the time to come up with some questions to ask everyone you speak with. This will not only make the best use of your time, but help you get a better handle on WHY you want to get into tech.

While you’re lining up folk to talk to take a look at job postings for the types of jobs you’re interested in. This will help give you a good feel of what types of things company’s look for. For me this really helped line up supplemental training/education (the whole experience vs. training question is out there, but more knowledge never hurts!).

One other thing you can do is look into volunteer opportunities. Many NPOs and community organizations are looking for help and have some interesting projects. At the very least these will help you better understand what you’re getting into and help focus your thinking. Also, they tend to not require 100% of your time, allowing you to stay at your “real” job while you feel things out.

Above all keep a good eye on WHY you want change, and while it may not happen overnight, eventually you’ll find a spot that makes the best sense for you.

YOU are the expert now

One of the first big IT projects I ever worked on was updating and replacing an ERP system called IFS. At the start of the project I was just an IT help desk tech (the guy who replaces your monitor or installs a printer). I was asked if I wanted to become the IFS Project Management Module expert, to which I readily said “sure, that sounds fun” (not to mention more interesting than installing printers).

Problem was I didn’t know anything about IFS…. or about Project Management….

---

I’m the expert?…

I have a two-pronged approach to solving challenges like this. The first is to have faith in others. In this case my job would involve traveling to multiple sites and standing in front of a room of professional Project Managers as the IFS Project Management expert, despite knowing basically nothing about either. The enormity of this (and the rather large knowledge gaps!) required me to have faith in my manager (who clearly thought I could handle things), my team (who supported me immensely) and myself (who learned to step up)… and this helped me not panic.

The second prong I use is to have faith in my myself. We’re all aware of our own capabilities, as well as our own limitations (be honest with yourself on these!). Once I really understand the challenge, I can map out possible gaps and determine solutions to those… generally this requires learning more about various topics (in this case IFS fundamentals and project management concepts) and boils down to doing my homework.

---

Don’t Panic - aka Have Faith in Others

Trusting those around you is hard. It requires giving up some amount of control and allowing others to dictate some aspects of your life. In most situations, I have enough faith and trust in the people I work with to make the best possible decisions for me in situations like these. This is doubly so once I have a working relationship with them and understand more about how they work.

When asked to take on incredible challenging , generally unknown, requests, I always remind myself that I wouldn’t be asked to do it if someone didn’t think I was capable. In most cases the person asking has more experience in the area than I do, further giving me confidence that I can do the thing (otherwise why would they ask?).

---

Do Your Homework - aka Have Faith in Yourself

Having faith in others is great, but it’s not enough. In order to succeed at this big asks, you also have to have faith in yourself. This includes faith in your abilities, but also in your potential. Over the years I’ve come to enjoy trusting in that potential since it has allowed me to flex and grow in ways I would not have without that opportunity.

For me, this frequently takes the form of (literal) homework. I’ve found myself enrolled in community college courses, teaching data analytics courses (teaching is a great way to help reinforce and learn new skills), reading stacks of books, and getting lost in the guts of a new system (one of the best ways to learn them, but always be sure you have a sandbox!). Since I also had a job, all of that had to be done on my “free” time.

---

I am the expert

It takes time, but eventually you’ll begin to accept these opportunities as pathways to growth instead of something to fear. For me the cycle of insane ask, not freaking out, working the problem and growing has become somewhat of an addiction. Not only have I built technical skills, I’ve had the pleasure of working with some very smart people (and made some great friends).

If we’re not being pushed by ourselves or others, we’re not growing, so grab every opportunity you can and enjoy the ride.