Geek 2 Man → The Journey from Engineer to Manager

April 8, 2021

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.

February 16, 2021February 16, 2021

What Makes an Effective Leader?

With a little work and the right processes, I believe anyone can manage others. But what does it take to not be just a manager, but a leader? How can you inspire others to do more and be more?

Lead by Example

I know, that sounds so trite; and how do you lead by example when your role is not the same as those you are leading? This has nothing to do with writing good code, or trying to keep a Sprint on task. It has to do with passion and inspiration.

What’s the end goal of any company? Profit. How do you make that profit? Keep your customers happy, make them feel like the company cares, make them want to not just stay, but tell others and get them to become customers too. It know it sounds a little abstract, and it is. But bear with me…

There’s a reason companies, and even organizations within the company, have mission and vision statements. They may even sound a little cheesy or obtuse, but they’re there for guiding customer experience and success, and that’s where the leading by example come in to play. A good leading is passionate about these and that passion shows in meetings, in presentations, and in how problems are solved and decisions are made. That passion helps others see how their actions can (and should to some extent) drive towards a common goal.

Sometimes it’s obvious, like fixing a major pain point in the existing system for the customer, or delivering a new solution that’s been asked for by numerous customers. Other times it’s not quite as obvious, such as improving stability. Let’s face it, most customers aren’t going to notice going from a 99.8% uptime to a 99.9% uptime, or that their larger reports now run 30 seconds faster, but that’s not the point. The point is, you improved it, and a leader’s passion is paramount to this success.

Inclusion

I would hope that it goes without saying that your team needs to feel as though they have a say in matters. They need to feel connected and in control of the actions and processes that lead to the accomplishment of the team’s goals or the final decision in an upcoming project or process change.

Soliciting feedback is great, but it’s not the only way to ensure that the team feels included. They need to feel safe to be able to come to you issues, both professional and personal. You team needs to know that they can talk to you on the side about anything that is bothering them and know that you’ll support them however you can and that it will remain confidential if the topic needs to remain between the two of you.

Helping improve the inclusion of your team is done through…

Listening

You can’t just talk to your team and expect them to go along with you, no matter how passionate you are. You need to listen. Not just hear them, but listen.

Some of the best ideas I’ve helped to implement over the years have been because I listened to what my team had to say. Sometimes it was listening to good ideas, which then lead to discussions over how to implement them. Other times it was listening to feedback about me, and how I was not as effective as I could be for them. Regardless of the topic, improvements would not have been made if them team didn’t feel as though they would be heard.

Listening to your team also helps you to understand what it is that motivates them. You can’t always give raises and promotions no matter how much you may want to. What you can do though is listen to know who on the team wants praise for their work, who needs public recognition (and who doesn’t want it at all), and who just needs a simple thank you from time to time in order to remain motivated.

Care

It sounds a little silly writing it down, but it doesn’t matter how much you listen if you don’t care about your team, their success, or their well being. If you’re not sincere in what you say and do with your team, they’ll know. There’s nothing that kills a person’s morale and productivity than a leader that is perceived to not care.

As easy as it sounds to just listen and care and be passionate in what you do so that you can lead by example, it’s not. It takes time. It takes practice.

February 1, 2021February 1, 2021

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.

January 23, 2019January 23, 2019

Schrödinger’s Engineering Team

Hopefully, you’re already familiar with the thought experiment of Schrödinger’s Cat. The concept of a cat both simultaneously alive and dead, existing in a dual state until observed, is one of Quantum Physics’ greatest visualizations.

Alas, a poorly informed engineering team can also exist in a dual state. However, unlike the hypothetical cat, they have a greater tendency to collapse and loose all productivity rather than being able to both work and not work at the same time.

I was recently in a situation where my team was asked to complete a set of tasks for a core piece of functionality in our new product. Midway through the sprint, word came from upper management (via our Scrum Master) that they were looking into third-party vendors to perform this exact same piece of functionality. Better still, even with this new information, Product did not terminate the sprint, and we were required to continue on what could very well now be a useless task.

At that moment, we became Schrödinger’s Engineering Team. Our Sprint suddenly existed in a dual state in which our tasks would be completed and provide value to the organization as well as all the work would still need to be completed and yet be absolutely useless to the organization. Talk about a morale killer!

Information is always important, but adding direction to the information is just as important when giving it to an engineering team mid-sprint. If the information would change the direction of the current sprint then Business needs to consider also prematurely ending the sprint. While terminating the sprint may be a little frustrating to the team, it certainly won’t have near the long term morale issues that continuing forward in a dual state will have. That doesn’t mean you should hold on to the information until the end of the sprint though. Doing that will merely aggravate the team, drop their morale, and cause them to trust you even less. On top of that, you’re also wasting the organization’s time and budget by continuing the sprint with what could potentially be useless deliverables. It’s better to cancel the sprint and regroup than to deliver unneeded or unusable product.

So how do we avoid creating Schrödinger’s Engineering Team? Just like Quantum particles, we need to observe the team. We also need to observe the information we give to the team, in particular with how it relates to the in-flight sprint. Then make a decision, with the team’s help if necessary, based off of the observation of the information. Don’t just leave them in a dual state limbo.

November 1, 2018

Privacy Matters

By now you’ve all heard about GDPR and how it affects just about everything you do with data. The sad thing about it is that the bulk of it is really all common sense when it comes to the use of Personally Identifiable Information (PII). Of course, we all know that common sense isn’t very common either…

I received an email from a recruiter the other day which brought privacy matters back into my mind again. I’m used to getting various emails with all sorts of different job opportunities or even just introductions. This one though caught my attention. It wasn’t the email content, or the job opportunity (it was actually saying that there were possibly multiple openings all over the place and I could pick and choose), or even the awful formatting that it was in (please stop copying content from Word, complete with random bolding and highlighting, into your emails without reformatting it!). It was the email distribution list. Instead of relying on an email service, or even adding multiple emails in the BCC line, this recruiter added 207 emails to the CC line…

Is my email PII? The US Department of Labor says it is (and the EU’s GDPR legislation agrees).

Further, PII is defined as information: (i) that directly identifies an individual (e.g., name, address, social security number or other identifying number or code, telephone number, email address, etc.) or (ii) by which an agency intends to identify specific individuals in conjunction with other data elements, i.e., indirect identification.
– US Department of Labor

I emailed this recruiter back, chided them for not respecting my privacy, and due to that requested that they remove me from their system and to never contact me as since I could not trust them with something as simple as an email address, how could I trust them with client confidentiality and any other information I might give them? I did get an apology from them along with a promise to remove me. Who knows if they really deleted me or not…

I know I was making a bit of a mountain out of a molehill. At the very least, it could have turned into another Replyallcalypse with a flurry of resumes and queries going out to everyone. Worse would be someone using that list of CC’d emails to attempt to access our various professional and social accounts and such. Enough of the speculation though. After all, common sense says that “this information wasn’t meant for me, so I should ignore and delete it.” Right?

As an engineer, privacy is critical. You should only be looking at the specific data you need to complete your task (such as fixing a bug that happens only to User X). If you’re using data to achieve a larger task in the system, you should only be referencing the data you need for the task (no more “SELECT *” SQL).

As a manager, privacy is no less important. You’re the next layer of privacy defense, helping to ensure that your team is producing privacy compliant software, regardless of if it is GDPR, HIPAA, PII, or just plain common sense.

Avoid The Replyallcalypse and keep your employees’ and customers’ data safe; only use what you need, when you need it, and avoid the CC field at all costs. You don’t want data loss to be yor folt…

October 12, 2018October 12, 2018

The Feedback Loop – How Agile is your Hiring Process?

We are agile in our development processes, especially in terms of striving towards continuous feedback. Why do we not allow for this same feedback loop to occur with interviews as well?

One of the key tenants of agile development is the idea of continuous feedback. The faster we learn where we deviate from the request the sooner we can correct course. And usually, the earlier we correct course means there is less effort required to do so. I don’t really need to continue on about the dev cycle here, do I?

Here’s the catch though: We don’t do this feedback loop often enough with each other as individuals.

Let’s skip the discussion over performance reviews for now. Depending on how often they are scheduled (quarterly, annual, only when things go wrong?) and how they are formatted, they qualify at some level as a feedback loop.

The key item here is that there is no standard or expected feedback loop in the interview process. It’s the rare manager and interview process that will give feedback to the candidate.

Let’s say you have three interviews, all for the same level position, and all three companies have the same interview style and code challenge types. After your interviews with Company A, you find out that you are no longer in the running. No big deal, right? You still have two more to go. Next thing you know, Company B rejects you. Both times it was right after the code challenge. Did you make the same mistakes on moth challenges? After all, they were both about creating a basic blog service from scratch. With a little feedback, even general commentary, you might have had the chance to study up and not make the same mistake the second time. Now you’re on your third try, and guess what, it’s that blog service again…

Had the earlier companies given feedback, you would know where your weaknesses were. It still may not help you get the next job, but it would at least give you the opportunity to improve your skills in areas others think you are lacking.

For example, if company A came back and told you your skills were great, but they didn’t like your attitude, you’d know to take a deep breath and be more personable and down to earth the next time. If company B told you they didn’t like how you named your variables in the code it may not help you much, but if they told you that you made too many database queries for the same data points you’d know that maybe you should look into how to better use the Objects you had built. You get the idea. A little feedback can go a long way sometimes…

There’s also the personal part here. Too often we treat our candidates as mere numbers. Did their resume check all the boxes of things we’re looking for? Did they show up for the interview on time? Are they local? Is there anything else we can use to weed them out because we have so many candidates and feel overwhelmed?

I know it’s overwhelming at times as the hiring manager to have so many resumes and candidates to sift through. It’s just easier to reject and move on, right?

Maybe.

But if you’re a company that prides itself on relationships with its customers and how great and communicative your culture is in the office, why wouldn’t you extend that communication and personal touch with all the candidates you interview and reject? If you can point to specific items, do so. If not, there’s nothing wrong with a “sorry, but another candidate was even more qualified than you.” At least the feedback loop has occurred and the candidate can move on.

As a hiring manager I do everything I can to make my candidates feel comfortable, and then to let those that were not selected know as soon as they are out of the running with a reason why. It’s not always in depth, but if they fail the code challenge, they get a general idea of what went wrong. If they’re not experienced enough after a discussion, I let them know. If the job requirements change mid-stream I let them know that too (Hey sorry, it’s not you, it’s us).

Agile isn’t just a development cycle or a catchy buzzword. It’s a mindset. I’ve been on both sides of that hiring desk, and the companies and candidates who have the Agile mindset always come out on top.

August 24, 2018

Transitioning from QA Analyst to Scrum Master

I had another great question from someone on LinkedIn and I thought I’d share it and my answer here.

I would like advice on career advancement in Software Development and becoming a Scrum Master. Currently, I am a QA analyst and was wondering is it a smooth transition for someone with that skill set?

Congratulations on wanting to become a Scrum Master! Yes, I think it would be a relatively smooth transition for a QA Analyst to become a Scrum Master. I’ve actually seen several QAs become Scrum Masters and several Scrum Masters take on the extra duties of QA to assist the team when they need it.

As a QA Analyst, I’ll presume you’re one of the last steps in the development process before things are approved to merge into the master branch and/or deploy to production. As you’re already the final say in the definition of the task being done, it’s not a big step towards helping the team adhere to their overall Definition of Done.

You also already have a solid set of skills with creating and following a test plan. That easily expands to following the Scrum process and helping to enforce it both in the team as well as with the product owners. The hardest part (in my opinion) is keeping the external influences at bay to allow the team to focus on their current Sprint.

The hardest part of your transition is probably going to be actually getting the job. The easiest way would be to try and move within your current company. You already know your way around, and they know you (which is hopefully a good thing on both sides!) If there’s another Scrum Master there, pair up with them, learn from them, and ultimately get a team of your own to work with.

A brief side note: Many organizations now I’m finding are starting to merge the Scrum Master in with a Project Management role. They think that they can have one person do all of it. Sometimes you can, but most times I think it’s best to have these roles separate.

While you’re doing all that, I’d look into becoming a Certified Scrum Master. It’s usually a two-day class and it covers everything you’ll need to get your feet wet. From there try practicing Scrum on some small projects at home. It’s a little unusual to clean your house using Scrum, but it will help you see how to break the tasks down as well as estimate times and determine what Done means. Then on your interviews, while you may be “green”, you can discuss how you’ve been utilizing it in areas other than IT. It shows that you have a clear understanding of how to utilize Scrum processes in any scenario. The best and worst thing I ever did was teach my wife Scrum…

I hope that helps some and I haven’t rambled too badly. If you have any other questions, don’t hesitate to reach out to me.

August 1, 2018

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.

Geek 2 Man

Posts