Posts

Posted on

I’m Not a Point of Failure

When it comes time to ensure that there is redundancy in your organization, how do you refer to that necessary redundancy? I recently came across an example that quite honestly, made my skin crawl…

Having “name” as single point of failure should be addressed.

See the key word in there? Failure. To make matters even stickier, the person this sentence was referring to was on the email. How would you feel being referenced in an email by your boss as a point of failure? This is demoralizing. I don’t care how much I know that I may be the only person in the company who can do a certain job, but I’d rather not be referred to as a point of failure. Personally, I’ll tell you that I’m not a failure, I’m a specialized expert who needs a back up.

So what do you call that singularity of expertise that needs a back up?

I had a manager once who referred to it as the Bus Factor. Yes, Bus Factor, as in, how many employees need to unexpectedly be hit by a bus before this function can no longer be performed? A bit morbid perhaps? Well, a little… But think about it. Nobody knows if they’re going to get hit by a bus. Nobody wakes up in the morning planning on stepping in to the street right in the path of a moving bus. Some people like to call this the Lottery Factor, but winning the lottery (or leaving because you found another job, which can sometimes feel like winning the lottery ) takes effort and planning. Getting hit by a bus is unexpected. The upside is that it’s not even terminal. You could just be laid up in the hospital for several weeks recovering. That’s still long enough that you would need a back up for your tasks.

Bus Factor 1

This is where there is no back up. Only one person needs to be “hit by a bus” to cause problems in the company. This is the “single point of failure” mentioned in the snippet of email by the one manager up above. As a manager, you don’t want to have this scenario longer than is required to identify and train a back up. That training may just be having documentation and a process in place to grant the appropriate access to anyone else on the team if the need arises. Still, avoid Bus Factors of 1.

Bus Factor 2

Great, you’ve got a back up in place. Two people are capable of performing the specific task. Is this enough? Well, now it’s up to you to decide. But you have a plan in place and someone who is capable of performing the the task in case the primary person is hit by a bus. So you’re at least in a stable place.

Bus Factor 3 (or greater)

Obviously the more people who can perform a given task or have the knowledge to do it, the better. At this point you have solid documentation over tasks and roles, and with a little training you could start swapping people between teams with minimal risk.

Bus Factor 0

Oh dear. You’ve identified a need in your organization. Maybe it’s because the single individual who performed the task has actually won the lottery and just turned in their notice. Maybe you’ve identified a hole in your processes where it turns out there never was anyone who did something and the team has stated that someone needs to be accountable. Regardless, if you ever find yourself in a Bus Factor of 0, do yourself and your team a favor and plan for a Bus Factor of 2. You never know when someone is going to get hit by the Lottery Bus…

I know, Bus Factor sounds a little cheesy and a little morbid, but it’s still better than “single point of failure.” Having a Bus Factor (or even a Lottery Factor) makes the personnel back up issue sound like a process statistic. It’s something that you can fix, and your singularity of expertise is still great at their job. There’s nothing demoralizing about a process statistic. Calling someone a point of failure implies that they just don’t do their job correctly, not that they are the only person who knows how to do their job.

Oh, you thought I’d just leave it at that? Sorry. You know I had to look up the origins of the term “Hit by a bus” while I was at it. To find the origin we have to go back quite a bit, to the 1907 novel The Secret Agent, by Joseph Conrad.

But just try to understand that it was a pure accident; as much an accident as if he had been run over by a bus while crossing the street.

But don’t take my word. Feel free to read it for yourself…

Posted on

That “Ah-Ha!” Moment

I was asked recently when my ah-ha moment happened when I knew I wanted to be in management.

I had to think  moment, and then I realized that my career has actually been a series of revelations, not just a single one. So bear with me as I back up for a second and have my little moment, much like Miriam Maisel during her wedding speech…

When I was younger I wanted to know how everything worked. No, I didn’t take things apart and try and reassemble them. Instead I built things. My parents still have the wind chimes I made out of metal conduit and a metal junction box… It was this building and experimenting that made me have my first ah-ha moment. I knew that I wanted to study Physics.

So off to college I went. A B.S. in Physics, and an M.S. in Electrical Engineering later it was time to find a job. Not the kind of job I had all throughout school building websites (I kinda enjoyed it and seemed to have a knack for it), but a real one where I had to go in to an office and do something. I liked the science side of things, but I liked the programming side too, so two resumes went out. Each one highlighting a different set of skills.

Wouldn’t you know it, the programming resume got some good traction, and off I was programming websites. Not just any site mind you, but the e-commerce site for Nokia in the US, nokiausa.com. It was there that I honed my skills and put all that education to use by solving problems in unique and creative ways. It was there that I had my next ah-ha moment. I know that I truly enjoyed programming, enjoyed seeing the instant results of things working, and that there were thousands of people who were using something I had helped to build. You could say I was hooked.

Several promotions and companies later I found myself in a slightly different role; the role of team lead. There was still programming, but there was a lot of mentoring the more junior members of the team as well as being one of the points of contact for senior management to know what was going on with the project. I saw that by helping the other members of the team to grow and collaborate better allowed our team to deliver more than we could have individually. That excited me. As I shifted my role more I was able to help multiple teams deliver larger projects with less defects, and that excited me even more. It was during this time that I had my latest ah-ha moment: Being a successful manager was helping your team or teams to achieve more, both in their jobs, and as people in general. There are a few individuals I still keep in touch with as I greatly enjoy knowing how they are continuing to achieve greatness with (hopefully) some of the foundations I helped set down.

And that’s where I am now. Following my latest revelation that I enjoy managing teams and helping them to achieve greatness.

So that’s my string of ah-ha moments to date. I’m sure I’ll have more as I continue to grow in my career. And don’t worry, there’s really no shrimp in the egg rolls…

Posted on

Hiring a Ruby on Rails Developer

One of the biggest challenges I’ve run in to as a manager is writing the right job description for the right job title. Get that right, and suddenly the right candidates appear in your inbox (well, at least you’ve got a better chance of getting the right candidates the first time). That being said, let’s presume you’re looking to hire a Ruby on Rails developer. Maybe it’s for a new department or project, maybe it’s to augment an existing team. Either way, there’s three levels (in my mind at least) for a Rails developer. So what are the levels/titles and their qualifications?

Junior or Entry Level Developer

These are the new developers. Call them “entry level” if you will, as that’s what they are, entering the workforce. They’re generally fresh out of school, or they’ve just finished up a coding boot camp and are looking to change careers. Either way, odds are they’ll be great to augment an existing team, especially if it’s a well established team which enforces code reviews. Using the power of the code review to help them learn the nuances of the system and the enforce good coding practices (you did write tests and they do pass, right?) will help them quickly become a solid developer.

At this level you should be looking for someone with under a year of experience, but who has taken classes in the subject and can answer high level questions about the language itself. You’ll want to know that they have a firm grasp of the MVC (Model-View-Controller) architecture that Rails uses. Throw them a coding challenge if you must, but keep it simple, and look for well commented code with simple logic. Trust me, you’ll know if they head off in to the weeds on this.

On a side note here, I’ve taught a few boot camp classes, and some of the students who came out of it were pretty darn good. I tried to “sell” one of my students to a recruiter, who then told me that none of his clients would look at a some for a junior developer position unless they had at least two years of experience in the language. That’s pretty harsh and short sighted in my opinion. If these guys had two years of experience they wouldn’t be junior level!

Mid-Level Developer

To me, this is probably about 70% of the developers out there. They’ve got about two to five years of experience with the language, have probably gained their experience in at least two different companies, and are able to code just about any challenge you throw at them. They may or may not have exposure to multiple databases, but that shouldn’t matter.

They should be comfortable with SQL in general, and should be able to speak a little to the NoSQL side of things (which is pretty much just key-value document storage, so if they’re comfortable around JSON, they’re good to go in that arena, especially if they’re augmenting an existing team). Speaking of data and databases, can they adequately explain when you should consider using seed data, and what the pitfalls of it can be?

Ask about their testing habits. Are they strict about TDD (Test Driven Development)? Do they at least ensure that there are tests for the code they write, regardless of where in the process they write the tests? Ask about their preferred testing languages and why (don’t worry if it doesn’t match what you already use, they’ll adapt).

One key item I would look for here is how comfortable they are in the console. Can they use the Rails Console for debugging purposes? Being able to run around within the console to verify and debug things is a critical skill. Beyond just the Rails Console, do they use the Interactive Ruby shell (IRB?)  I’ve found that sometimes it’s helpful to just jump in a test a theory without having to worry about the rest of the Rails project.

Mid-level developers are great for augmenting existing teams as well as starting up new ones. They can generally hit the ground running after a few days of looking at the code base and can be a productive member of the team in just a few Sprints.  At the same time, they’re perfect for starting a new team if you already have a well documented project, and possibly a software architect who has given an initial thumbs up to the project.

Senior or Lead Developer

Here’s where it gets tricky. At this point it’s not just about how long you’ve been programming in Ruby on Rails. You could easily say that anyone with over five years of experience could be considered a senior level developer. However, it’s more than just the experience level. How much are the willing to help guide the other members of the team? Do they look at the junior developers and see potential and help them to learn and grow? Or do they just sit by and let them struggle? I’ve known some developers who have over a dozen years of experience, but have no drive to help anyone on the team other than themselves. Those guys will never be senior level in my mind. I’ve met others though who are such team players, and such leaders within the organization that they naturally fall in to a senior level even though they’ve only been doing something for three years. I’d be willing to hire someone with only three or four years of experience but shows solid leadership skills over someone with seven years of experience who is more interested in just getting the minimal amount of work done and just collects a paycheck.

These are developers who help make the product owners make decisions when they have questions over if a feature is feasible within the requested time frame. They can help to scope projects because they know what everyone on their team is capable of achieving. They push the other team members to become better. With the right senior developer on the team, the results you get from the team will truly be greater than the sum of the parts.

A senior level developer is perfect for helping get a new project off the ground. They can help make the right choices in the beginning of the project, and will quickly know where they will need the most help within that project, so you know what skills you need to hire in next.

They’re also perfect if you find that you have an existing team that seems to always be struggling to fully deliver. Let the senior developer come in and help try and correct any bad habits that your current team has. Have them help coach the team while they help pull the project across the finish line.

The Ideal Team

If I had to start a new, large project from scratch, I’d look for a four person team. I’d start with one senior level, lead developer. Once they are able to help analyze the project I would have them give their recommendations as to if we needed three mid-level developers, or if we could do a combination of mid-level and junior developers.

If I was augmenting an existing team, I’d look at the current needs of the team and the seniority levels of the existing members to determine what I needed. I know that this answer is a little more vague than all the rest, but it really does depend on the skills and needs of the team as to if you bring someone junior in to train them, or someone more senior to help grow the team for you.

Posted on

Can I See Your GitHub?

During the interview process I often get asked to share my GitHub account. Of course, then I get chided for not having much in it. In particular, I get questions about why I don’t have work from prior jobs in it.

Um, hello? Has anyone heard of a little thing called Intellectual Property these days? Seriously folks. Every job I’ve held has been a corporate job, and every job I’ve held I’ve had to sign something stating that all of my work is the property of my employer. This is one of the main reasons they pay me; to produce code which does things for them that their competitors are not able to do. If I were to go saving this on GitHub, or any other publicly accessible location, I could be liable for exposing industry secrets (OK, a lot of what I’ve done is commerce related, and a shopping cart is a shopping cart for the most part, but that’s not the point). If those little code secrets were really good (like proprietary algorithms, or better still passwords and hashes) I could find myself in a lawsuit. On top of that, I’ve just potentially exposed their security, making that particular site easier to hack or spoof.

Once I explain this I’ve still had some come back and ask me to share work in another manner. Wow. What part of Intellectual Property do you not comprehend? Even if I did have copies of my prior work (which would technically be illegal, even though we all know almost every developer has some snippets of code in their arsenal) why would I share that with you, once more potentially giving out competitive secrets? All I’m doing is showing you that I don’t care about the IP of any job I work at, including yours.

This is why I don’t share much on GitHub. I’ve worked hard and I’m not going to just hand out someone else’s IP, even if I wrote it, just to prove to you that I can code. I’ve been at this for 20 years. Please don’t insult my ability or integrity.

Curious about just how much I do or don’t share? You can see my GitHub account here: https://github.com/ercubed
(The only real thing shared, is the work I’ve done with teaching, so that all the students would have examples of the work once we were done with it.)

As for you hiring managers out there reading this: Do you really want to hire someone who has copies of, and is willing to share, other employers intellectual property? If they’ve done it with others, chances are they’ll do it with yours as well.

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.

Posted on

Welcome to Geek 2 Man

As a software engineer, scrum master, and, in my humble opinion, generally intelligent guy, I have often found myself sitting in meetings thinking, “I could do that.” and on a few other occasions, thinking to myself, “What in the world is that manager thinking?” And so my quest to leave development and enter the magical, mystical realm of management began.

This site exists for several reasons.

Think of this as a diary

This isn’t some super secret diary with a lock on it stashed away in the night stand. While it might do me some good to have one of those, it won’t server the full purpose: dialog. Let me get me thoughts out, and in exchange for reading my diary, I hope some of you will respond back with your thoughts. Tell me I’m nuts. Tell me you agree with me. Either way, ideas can’t grow or help others without the open dialog.

I like to tell stories

I’ve heard lots of great analogies over the years. Quite a few were stories when I first heard them. Others were just good ideas that then were turned in to parables (of sorts…) when I explained them to others. So why not share?

Consulting

OK, yes, there is an ulterior motive here… I’d like to think that some of my thoughts are good enough, or important enough, or even just entertaining enough, that maybe someone out there wants to pay me to use those ideas. Maybe that’s a speaking engagement. Or maybe it’s just for help with instigating change within their organization. Or maybe I’m just so darn handsome. The sky is the limit with what I can accomplish and what I believe I can help others accomplish. Like what you see? Let’s talk.

 

It’s because of this journey of being a geek to becoming a manager that this site exists.