Notes from the Field: Building Engineers

Brief history:

My last job I was lead over 10 engineers and we would not hire Sr. engineers, so I had to develop engineers from people willing to work temp to perm for 2 years with no benefits.
When I took over as lead of network engineering the jr engineers were not being developed or used. I did not like working all the time and saw right away I had to develop others to run the day to day tickets, so I could develop solutions to meet future business needs.

Solution:

1. We had 2 good engineers at that point, so we started mentoring the engineers that were willing to learn and pushing them through the CCNA. The CCNA is the foundation of the house, if it is not brain dumped.

2. Any purchases we made sure to get CLC’s and send people to class.

3. Jr Engineers were given a discipline or part of the OSI model to own

4. As they progressed in what they were given they were then moved along

5. Engineers were allowed to pick a discipline: r/s, security, wireless, voice. Etc.. and train in it

6. All trouble tickets are owned by jr engineers. If the jr engineer can’t resolve the problem in 45 minutes, they have to open a tac case and work with tac.

7. After the 1st round with tac they would engage with a sr engineer. This gives them a chance to fix or fail on their own.

Over time we built sr engineers using this.

Architecting and making things in a cookie cutter way and simplifying configurations allowed for the jr engineers to move from handling 20% of the work load to probably 70% of the work load.

This allowed for architects to design and not have to run a ticket queue.





Now that I work for a VAR the 1st thing I notice when I start working with a company is how they are using their jr staff, if they have any, and are they developing them.

Sadly, most places from the biggest (global leaders) to the smallest (1/2 billion) are not using their jr staff and they are not developing them. There always seems to be a few over worked engineers trying to run the day to day and deploy new solutions. Not design, they have no time for that, just deploy and figure it out on the fly.

How are the jr engineers used at your work?

What do you see moving from company to company, if you work at a VAR?

If you have been somewhere that was doing it right, what were they doing to develop the jr engineers?

I like #6 and 7. Thats a good simple strategy instead of trying to figure out which tickets get automatically pushed to sr engineers! I can only see it working if you have the man power to keep up with the tickets.

Currently my team is a disaster. There is only me and one other person with IT backgrounds and the rest have just been pushed into their roles. Over the past 5 years our department has slowly transitioned into an IT style team but no one besides me and the other IT guy can see this. Leadership is 100% project management focused and does not know how to run an IT team. Hell both supervisors dont even know the first thing about networking or system administration. They quickly get confused between RAM and Hard drives

I quickly lead on to this and thought it would be a great opportunity for me to steer the team onto a good track but all I get is resistance. "We are not your typical Enterprise network, so best practices don't apply" , "We dont have time to implement your suggestions, just focus on the projects". This also has lead to everyone on our team going in their own direction with little to no cordination between each other on projects. I can go on for quite a while on this...

Mentoring is a huge part of me. I love to teach others and help them grow (if they want too). We hired a new girl about 4 months ago straight out of desktop support with no server or networking experience. I was hoping my boss and her co-workers would setup a mentoring program with her or at least give her direction... Nope, nothing. Just here are your projects and get to them.

And yes, we are a team of 15 and there is only 3-4 of us who do everything. When someone elses system breaks they dont know how to TS or fix it, freak out then pull one of us in to save the day.

I miss a normal IT team...

_________________
http://blog.movingonesandzeros.net/

Thank you for the response.

I hope a few more people read and comment on this.

There is a real need to develop jr talent due to the fact most companies are willing to pay the price for sr engineers. This means someone has to mentor the jr engineers.

I will say, i feel pretty good when i look around town at network leads and directors that spent time working with me. I sit on the other side of the table now and see folks refusing to take time to develop jr talent, while drowning in work and unable to plain the next big project.

I've seen a pretty big failure in developing junior guys in my limited experience. Made the mistake of taking a VMware Engineer position back in June, (I miss networking) and we've had a situation arise that could easily be handled by the NOC instead of having to contact one of our team. There are only 4 of us so no real junior positions on the team. They wouldn't give the NOC the access required to fix the problem. They will never learn to do anything other than monitoring the data center since when the opportunities arise to do more they refuse to give the ability to do it.

HR talks big about promoting from within and allowing people to move around but without allowing them to get experience in other areas they will never move one into a higher position if it was available due to a lack of experience and knowledge in the required areas.

Sadly, that's an all-to-common situation.

I've suggested "lunch and learn" sessions at several places where I worked to present a specific IT topic and these are often well received, both by management and by the staff. Sometimes we even convince the management to pay for pizza or take-out - especially when we do one or two on our own and they see the interest and results. They also gave us a 90-minute window for these sessions.

When I worked at the Fed, the most junior team worked midnight to 8am. We did several breakfast presentations - management brought in bagels, the night shift stayed an extra 30 minutes and the day shift came in 30 minutes early. We did short, focused sessions like software install methods ("Avoiding a Spousal-Mode Installation"), network troubleshooting (ping vs. traceroute vs. using a service management tool to actually see that a device was responding intelligently.

Glenn

_________________
Lost: Rocket, appx 8' tall, Green w/ yellow fins, nose, and computer bay.. Last seen streaking skyward in NY

I like the train through lunch and learn.

Anyone else?

I've heard some of our guys talk about doing that but nothing has come of it.

I really like this. We did something similar in the military. We didn't work with TAC much but we did constant training sessions. I hate to say it but I believe it mainly works with teams of 7+... With less than that on a larger network everyone is expected to know everything already.

_________________
Discipline

"The only real security that a man can have in this world is a reserve of knowledge, experience and ability" - Henry Ford

I think you are right about the size of the engineering group.

Most of the smaller shops i go in dont have any jr staff.

I work at a huge multi national company and although they say that they want to upscale evryone and provide training, the office politics make it nigh on impossible to progress at anything more than a snails pace. So I have taken it upon myself to pursue the CCIE and I must admit when I did say that a few people sat up and took notice, will anything happen no I don't think so.

The idea about lunch and learn sounds really great and when I go in today I'll say that to the manager who is receptive to good ideas.

I like the idea of mentoring also and have tried to push that but with our training department stuck in their ways using boson netsim to train people who want to do their CCNA........... They sit in a training room surrounded by switches, routers and servers and they use netsim, I ask ya???

Sometimes it feels like you're dealing with jabba the hut!

_________________
Good Luck,

David

I've been an IT instructor for almost 15 years of my career and have done L&L sessions at almost every company. It takes a little effort and persistence to get it off the ground.

For L&L to work, you need to lay the groundwork.. Some managers may resist because they fear they will lose staff that get trained on additional technologies. Play the loyalty card - if a company trains you and treats you well, employees tend to stay in the company, even if they move to another department.

One person, likely the instructor or primary presenter, needs to put a basic plan of sessions together, ready to discuss with staff and management. You'll likely need a plan with "meat" to interest the staff, and a basic summary (we'll meet monthly in the all purpose room and discuss x, y, and z) for the managers. Planning the sessions can be a team effort, but having one person lead the charge to management is important to appear well organized.

Talk to other techs/engineers to determine interest, and document it. Get commitment from other senior staff to participate, both to see a new perspective and to share their experience.

Have the staff from other departments be your "moles" - see if their manager is receptive to the idea.

Meet with your manager and then other department managers to discuss the plan and show the interest of the staff. See if they are willing to possibly allow an extended lunch for these sessions, and ask if - after a few successful sessions - can they offer some incentives - a couple of pizzas, some old equipment for lab/demonstration, whatever. Invite them to attend.

After each session, send a brief summary with attendance list to all managers who's staff participated (or were invited), and - if appropriate, the IT director or senior management. This shows the direct managers the interest by their staff, and the senior managers see cooperation and information sharing that has little or no cost and visible benefits.

Another effective method that's often overlooked is when an outage occurs. Often, the senior engineers gather in the "war room" to brainstorm. Bring in a few junior people to observe, listen to their questions (they often still see trees while we're deep in the forest!) even if you defer the answer, and have a brief follow-up session to summarize the problem, the troubleshooting methods, and the result. If nothing else, it develops good troubleshooting methodology in your staff.

Glenn

_________________
Lost: Rocket, appx 8' tall, Green w/ yellow fins, nose, and computer bay.. Last seen streaking skyward in NY

Kudos on that, my last job all the network architecture was done behind the curtains by the senior engineers, we were just given orders to deply without really understanding. In my current job I am an active participant in the network architecture and design. I'll tell ya, I've learned more in about networking in the past 8 months than I did in the previous 4 years.

_________________
"If you're good at anticipating the human mind. It leaves nothing to chance."
-Jigsaw

I like that too.

The more you can let jr engineers own pieces of the network the quicker they learn and the less of the day to day the sr staff has to do. That allows for proper planning of the next project 6 months out instead of when the equipment hits the loading dock at the DC.