Category: Personal Skills

Posted on

Working Remote

I had the thought to write a post a while back, pre-pandemic, about the benefits to remote work, particularly in regards to employee mental health and productivity. Like so many of my ideas, I never wrote that piece.

Note to self: Write a blog post on procrastination someday.

But, as with so many things, COVID came through and changed everything. Offices were closed, home offices were quickly created in kitchens and living rooms everywhere, and people started to realize that their old way of working may not be all that effective anymore. So now I think it’s time to write my remote work post, but this time over how to be more effective as opposed to the benefits.

Keep Your Schedule

This is one of the most critical ones. Stick to your old schedule, or something close to it. Just because you don’t commute to an office now doesn’t mean that you have to be online and working for those 45 minutes (or however long your commute would have be). The same goes for quitting for the day.

It should also go without saying that when you’re done for the day, you’re truly done. If you didn’t bring your work home with you before, then why should it be tempting you when it’s just in the other room? If you did bring your work home, chances are that was part of your job anyway, and you should keep those routines as well.

Keeping to a schedule also helps to stop you from working too much, or at least it should. It’s amazing how much you can get done when you don’t have the constant interruptions of an office. Yes, I know that families can replace those office interruptions, but that’s a topic for another day…

Have a Dedicated Space

It sounds silly, and a year into the pandemic most of you have probably already done this. Still, it’s worth remembering that just as you had a dedicated space in the office (even in a flex-space, open-desk, office, you still had an official “work space”).

In the end, if you can help it, don’t have your workspace where you eat or sleep. Keep the main functions of life as separate as possible. If you can’t due to space constraints, at least try and sit in different locations. For example, sit at one side of the table for meals, and another for work.

Communicate

Offices have been going towards instant messaging over emails for a while now. So that really shouldn’t be all that different to you. The biggest change is meetings. Gone are the days of dashing between meeting rooms to make back-to-back meetings on time. Instead, it’s all virtual and you’re stuck wondering if you have time to top off your coffee before joining the next meeting. Still, virtual meetings can be a bit daunting. You’re either stuck with your camera on and feeling awkward with seeing yourself, or you’re presenting and have no idea what your audience is doing because their cameras are off. Either way, it’s just something to get used to.

If you’ve got to step away for a little while, such as for lunch, to run an errand, or just needing a break, be sure to let your colleagues know. It’s not like they can peek over a cube wall and see if you’re there. You don’t even have to let people know directly, just update your status in your chat tools. They’ll see it when they go to message you.

Just like in the office though, those messages can get overwhelming and/or annoying when you’re trying to focus on getting something done. If that’s the case, just turn off notifications for a while. It’s no different than in the office, just reduce your distractions to focus on the task at hand.

Dress for Success

Laugh all you want, but still dressing for work helps with the “I’m working” mindset. Don’t get me wrong, I love wearing a nice warm hoodie in the winter and shorts in the summer. That hasn’t stopped me from still putting some form of a dress shirt on though, even if it is more and more often that it’s a vintage short sleeve shirt with a big 1970s collar instead of the dress shirts I used to wear in the office. Having that “work uniform” helps put me in the right mindset to work. And when the day is over there’s another mental shift as I change over to a t-shirt.

Of course, it doesn’t mean that PJ pants are a bad thing from time to time. Let’s face it, comfort is paramount, especially when you’re slightly under the weather and still trying to make a deadline.

Embrace the Flexibility

This may seem to be somewhat contradictory to my advice on keeping a schedule. It really isn’t though. The schedule is your start and stop time. The flexibility is the time in between and on either side.

Taking a break is easier when nobody’s walking by looking for “butts in seats” thinking that’s the optimal productivity model. Some of the most productive people I’ve known in the past were smokers. They took their smoke break outside, away from their desk, and cleared their head or discussed the issue at hand in a different setting. The flexibility of working remotely is really no different. If you need a break, go get something done around the house. Let the feeling of accomplishing something roll into accomplishing the next task at work.

Flexibility also means changing your location. Work at the coffee shop one day, or even just for a few hours to change your perspective. If your wi-fi reaches, try the backyard. Use your phone as a hot spot at the dog park. If your boss will allow it, take a “working vacation” and work from another city for a week while exploring at night. As long as you can still be productive and get things done, the possibilities of location flexibility really are endless.

Decompress

My biggest takeaway though is one that took me a while to learn myself when I started working remotely a few years ago. You still need your private or “decompression” time. You’d probably chill out in the car or on public transportation on the way home and let some of the stress of the day fade away before getting home. That downtime is still just as important as it was before.

Turn that morning commute time you used to have into a walk around the block to prepare for work. Block off the last 30 minutes of your schedule to wind down with some music, an audiobook, or even some instructional videos on YouTube for a new hobby. Whatever you need to do to turn off your work persona.

Be sure to still get that “me time” in, especially if it’s a rough day. You and your family will appreciate it down the road.

Working remote isn’t the end of the world, even if the end of the world brought about more remote working.

Posted on

The Geek Returns from Sabbatical

I know… I know… I sort of let this blog just fall off the radar. Sorry about that…

To be quite honest, some of it was just pure laziness. However, there was a large secondary piece to all of it as well. You see, I went “backwards” in my career. I went from an Engineering Manager to a contract Software Engineer, and to be quite honest, it stung my ego a bit and made me question my career progression.

In hindsight though, it was a good move. It gave me chance to literally get back to basics and grow myself properly instead of just jumping into a managerial role and expecting to not only survive, but to thrive. I’ve spent the past few years building myself back up as a solid software engineer and finding my proper footing in leadership. It’s really only recently that I’ve been truly ready to start taking the next steps.

As I take those next steps I plan on documenting them here as well as my usual ramblings on the subject.

Posted on

The God Complex

When was the last time you walked on water or turned water in to wine? You haven’t? Are you sure? Because that “holier than thou” attitude you just gave the Product Owner over why that task couldn’t be done said otherwise.

Why do so many engineers insist on thinking that they’re better than their non-technical counterparts on the team? I’ve seen it time and time again (and quite honestly back in the day was a little guilty of it myself).

There’s nothing wrong with being proud of the knowledge and skills you have as an engineer. It’s true that not everyone has them. At the same time though, it’s not acceptable to hide behind the curtain of knowledge and give some hokey answer as to why something can’t be done. I don’t know how many times I’ve heard one of the following:

  • The system can’t do that
  • That’s a major undertaking that will take too long
  • The user is doing it wrong
  • It’s not my problem
  • It can’t be done

You know, with the right explanation, any one of those could be a valid reason. Yes, even the “It’s not my problem” one is valid. You just need to have a very formal process and clearly defined division of roles and responsibilities to be able to get away with using it. Even then, you should always offer up what individual or department is responsible.

If you’re pushing back because the user is doing something wrong with your perfect code it’s time to reevaluate your test cases and edge scenarios. It’s possible that the issue could be resolved with a little UX help to make things more obvious to the end user, but even then, they obviously did something that you didn’t expect them to do. It’s time to suck it up and admit that your code wasn’t as perfect as you thought it was. Now go write some unit tests to cover this new scenario and write some code make those tests pass. While you’re at it, talk to the QA team and your Product Owner and see if you can come up with a few other potential edge cases to handle. If your users found one, odds are they’ll find another.

Claiming the system can’t do something or that the change will take way too much work to do are similar in nature and can be handled the same without coming across too high and mighty. Let’s face it, some requests really can’t be done easily with the current code base and language or the current system architecture. If that’s truly the case, than come out and explain why it’s the case.

As a manager, there’s nothing I liked more than having an engineer tell me that something would take too long to do or that it would break the current system with no better explanation than that. I’d have lunch at my desk, or do a little work that night, and turn around and send a branch of code to the developer with the solution the next day. Please, don’t tell me something will take weeks to complete when I can solve it in two hours while watching a bad movie.

The worst offender in that list is “It can’t be done.” Odds are you’re not being asked to do quantum computing on an old 386 desktop computer, which would truly qualify for that statement. I’ve heard “It can’t be done” more often than not when it’s something that can be done, but the engineer doesn’t know how to right away, or has never done it before. If you hear “it can’t be done,” push back and ask if it can’t be done or if they just don’t know how to do it. Chances are they’ve never done it or don’t know how to do it and are afraid to come out and admit that hole in their knowledge and lose the mystique surrounding what they do.

Of course, sometimes the entire reason behind any one of the “excuses” is really just that; an excuse used to try and hide the engineer’s laziness. If they’re just being lazy and don’t want to do it, that’s a whole different issue…

As engineers, we need to stop trying to cover up our short comings with cocky attitudes. We need to admit where we are lacking and seek the knowledge (and assistance) whenever possible. We need to give sound reasons to back up our statements, especially when they are deemed negative by the rest of the organization. If we want to be the gods of the organization, we need to do it with humility and helpfulness and have others bestow the title on us. We cannot do it just because we think we’re good enough or, worse still, better than everyone else.

Further Reading

Programmer Culture and the God Complex

Posted on

Always Think Things Through

Every time I think I have a brilliant idea I stop and think about any possible unforeseen consequences before I continue. Why? Well, I remember back to when I was growing up and had a brilliant idea (I was full of them) and my parents we good enough to let me “experiment” with my ideas. This particular brilliant idea was about me making a chocolate soda…

Chocolate soda seems like such a simple concept, doesn’t it? After all, it’s just chocolate and carbonated water… So I took a small bottle of club soda, took a sip to make space, and then filled the bottle back up with Hershey’s syrup and sealed the cap. What’s the best way to mix liquids in a bottle? I hope you said “shake it”, because that’s exactly what I did. Let’s just say that when I opened the bottle to take a drink the outcome wasn’t quite what I was expecting. A change of clothes and a cleaned up kitchen later, I had learned a valuable lesson; think things through a little more before starting to work on a great idea.

If you stop and think about it, it’s really not all that different from Test Driven Development (TDD). You know what you want the code to do, so you write a few tests, then you write to code to make the tests pass. As you write your code you see a few edge case scenarios, so you write tests for those. Then you work on making all your tests pass. It’s about thinking through all the steps as you go.

Granted, in true TDD fashion, I should have first verified that I could open a bottle of club soda, then taken another bottle and vigorously shake it like I was mixing something in it and open it… Of course, during that test I would have only sprayed club soda everywhere, but that would have avoided the chocolate disaster, right?

At least I wasn’t building a bridge…

From Test Driven Development across Java, JavaScript, and Perl by Aaron Cohen

There’s plenty of options for writing and running tests, so there’s no excuse for not finding an option that works for your project and the programming language(s) involved . The bigger item is making sure that they’re actually written and used. Then your developers are thinking things through and you might actually catch an issue before it goes in to production, even if it takes a while.

I’m not saying that would have saved me from spraying home made chocolate soda all over my parents’ kitchen though, after all, I didn’t know about TDD back then…

Posted on

Asking the Right Questions

I once worked for a CTO who had a very different leadership style than any other manager I had ever worked for in the past. He pulled from several different management techniques, but was ultimately rooted in the Socratic Method. Yes, he asked questions. Better still, he encouraged questions from those around him.

If you’re not familiar with the Socratic Method, it’s actually rather straight forward. This is the practice of teaching by asking open-ended questions with the intent on the students answering through examining their knowledge and beliefs. It is done to get students to think on the fly and not have to always rely on straight fact memorization. This discussion among students (and the instructor or leader) also adds the benefit of everyone involved buying in to the proposed answer, or at least knowing their their dissent was recognized and discussed and not just dismissed.

This CTO would quietly sit in meetings and listen. When the meeting was about over he would pose one, maybe two questions, and then watch and listen as we debated further. Occasionally he would have a predetermined outcome he wanted us to all reach, but more often than not he was just as interested in our discussion and path as we were.

More than once I would find myself in a one on one discussion with him and the only thing he’d say was a variant of “you make a valid point, but what is the real question you are trying to solve?” He challenged me to think deeper; to try and find the underlying question to the problem I was trying to solve. Some days it drove me crazy, but then I’d have that epiphany when I hit upon the “right question,” and it all became clearer to me.

I have always been inquisitive. It’s just my nature to ask questions. However, watching him in action was enlightening. I could wax poetic about how he had elevated it to an art form.

Those who didn’t like his methodology felt he was ineffectual because he didn’t always have a clearly defined agenda. They couldn’t have been more wrong. He knew what he wanted to achieve from the very beginning, but he asked us questions which in the end made all of us feel as though we had the ideas. In turn, that gave us a deeper ownership in the project as individual contributors as opposed to just receiving marching orders and being told what to do.

Since working under this person I’ve tried hard to “step my game up” with Socratic Management. I’ve tried to not just manage those around me, but lead them by asking questions and getting them to buy in to the ideas I have on their own. I’ve had some strange looks from some people, and have even had a few tell me that they’d rather just have me tell them what to do instead of asking all those questions. That’s fine, and I am happy to adjust for them. Others though really took to the questions, and I’ve watched them grow and become leaders in their own rights.

I still hear that CTO as a little voice in my head, telling me “You still haven’t asked the right question.” It drives me every day.

Posted on

How Long Until You’re Truly Effective?

I had a boss once, who in the middle of an important meeting exclaimed, “I think I’m finally starting to understand!” and then proceeded to explain how it takes a new manager nine to twelve months to truly understand the environment they are working in. He was just past the nine month mark when he blurted that out, and he couldn’t have looked happier. It turns out that he once had a boss who did just about the same thing as well.

There’s plenty of discussions out there over how long it takes a new employee to get up to speed. Thanks to our instant gratification world, an astonishing 27% of executives think that an entry level employee will be successful or not in the first two weeks. That number reaches 78% when the time frame is at three months.1 While I’m all for using your gut feeling on people, and there are some that will certainly stick out as awesome or awful in just two weeks, two weeks is just not enough time to navigate the waters (especially at a large company) and show what you’re capable of.  According to one study, it takes up to two full years for a new employee to become as productive and effective as the prior employee.2

And just think, that’s only a new individual contributor.

Let’s say that after three months, the new employee is at 80% productivity. That’s pretty good. But what about the new manager? If this person is new to the company and wasn’t promoted from within, then they have to learn the product, learn the company, learn the culture, all on top of managing a team and learning their strengths and weaknesses. You would be hard pressed to be operating consistently be at 80% effectiveness at the three month mark. You could safely double that to six months and you’d be getting close. But at nine months to a year, that’s enough time to fully immerse yourself into the company’s culture, product, and processes, to the point of comprehending some of the nuances that would not be so obvious when you were only three months in.

So as a new manager, don’t worry if it feels like you’re not as productive as you were down in the engineering trenches as soon as you change roles. Just keep working hard, push forward and ask questions. Your effectiveness and  understanding of the job will come.

Existing managers, please be sure to do all you can to help those who are just stepping in to the management role, especially if they are new to the company as well. Remember that it takes time to be effective, and please be sure to give them all the tools and contacts they’ll need to be successful. You’ll be glad you did.

I’d like to add one more link in there though, to Harvard Business School’s article on getting new managers up to speed.3 While it doesn’t back up my time frame claim (or even give timing), it does give some very good advice over how to help new managers succeed, and that’s something I want to remember in nine month’s time…

Resources

1. http://fortune.com/2015/09/18/new-employees-onboarding-training/

2. http://www.nxtbook.com/nxtbooks/trainingindustry/tiq_2012winter/index.php?startid=40#/40

3. https://hbswk.hbs.edu/archive/getting-new-managers-up-to-speed

Posted on

Both Sides of the Table

I’ve been through more interviews in my career than I’d like to admit. I’ve also been the hiring manager. In the end, I don’t know which is more stressful. Sure, as a candidate, you want the job (or at least I would hope you do, otherwise why are you wasting the interviewer’s time?), and if you’re currently unemployed it’s even more stressful. I get it. But stop for a moment and think about it from the hiring manager’s point of view…

The hiring manager is taking time out of their busy day. Time that they could be handling any of their regular duties. Time that very well may now have to be spend after hours catching up. If it’s a smaller company, they’ve already spent time reviewing every resume that’s come in. If it’s a larger company, they’ve still spent time reviewing everything that has already been filtered down for them by a recruiting team.  At the very least, when you walk in that door for an interview, you should have a smile on your face, thank them for taking time out of their day, and I hate to say it, but look like you actually attempted to get dressed to impress someone and didn’t just pull the clothes out the laundry basket.

What? Dress up for an interview? I know… I know… You think I don’t understand. It’s a casual work environment, everyone is in shorts and sandals, so it’s OK. Sorry, it’s not. As an engineering manager, I’m looking for engineers (duh). And what is one trait that engineers are good at? Engineers are detail oriented. When you walk in, all disheveled, unless you apologize because you just changed a tire for a little old lady on the side of the road, I’m going to presume that you are not detail oriented. Is that harsh? Probably. Still, what harm is there in showing up without too many wrinkles in a dress shirt? If everyone else shows up in jeans and a polo, stand out with khakis and a dress shirt. You can always dress to match the environment after you get the job.
(Before anyone goes and chides me for being sexist here, just know that I have never seen a woman show up for an interview in an outfit that is anything less than professional. They have always been smartly dressed. I have yet to see a woman show up for an interview in Birkenstock sandals and dirty feet!)

I know interviews can be nerve racking. Sometimes you’ll stumble, and forget answers to technical questions that you know you know the answer to. Don’t worry, don’t panic, take a breath and approach the answer from a different angle. Explain that you are embarrassed that you can’t remember the actual term, but here’s the explanation over how it functions. Ask to get up and draw it out on the white board. Don’t just say I don’t know or I don’t remember; turn it in to a discussion to show your thought process (as long as you stay on topic!)

What about after the interview? Some people say that you should follow up in a few days to see where you stand. I’d be careful there. Too soon and the manager may not have had time to fully compare you with other candidates. Too late and you may be forgotten (let’s hope not!) Too often and you risk aggravating the manager. I know one manager who would actually reject you if you called too many times to find out the status of your application. I guess the squeaky wheel doesn’t always get the grease…

Here’s where managers need to step up a little. I know things are busy, but as soon as you know the candidate is not the right candidate, let them know. It can be as simple as a form email or, if they’re exceptional, but just not the right fit, you can personalize it to let them know your reasons for hiring someone else or give encouragement over other job types you recommend they look at based off of what you learned about them (nothing wrong with telling someone that the role they applied for is “too junior” of a position for someone of their caliber.)

As a first time manager, remember the pains you had when you were on the other side of the table. Help the candidate feel at ease. Communicate with them before, during, and after the interview process. You don’t have to hold their hand, but you should come across as human to them. If you don’t, you run the risk of them not accepting your offer.  No matter what though, be sure to let the candidate know if they are not moving forward in the process. Under no circumstance should you leave them in the recruiting black hole, with no way of knowing where they stand.

Hopefully this is all common sense to everyone. I just have yet to see this sense in common use.