Month: January 2018

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

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.