Tag: engagement

One thing I’ve noticed during my time as an engineer is an over-reliance on technology to accomplish all communication ends. By this, I mean that an engineer will sit at their desk and exchange a series of 20+ emails and instant messages to discuss a topic that could have been resolved with a two-minute face-to-face conversation.

Let me begin the discussion by saying that I am a text message fiend (as in, I send over 1000 a month). I’m also a mild Facebook addict along with Twitter, email and various other social networking sites. What can I say, I enjoy talking to a lot of people in a variety of ways. There is nothing wrong with having some level of dependence on networking and communication tools; in fact, I wholeheartedly encourage people to reach out and communicate by any means at your disposal. The unfortunate side-effect of our technology-driven society is that somehow, the longest-lasting time-honored and effective tool we have, has been largely forgotten: face-to-face communication. Now, phone conversations also suffice for this to a large extent, but there is something about looking in someone’s eyes and watching how they elaborate on their topics with body language as well as voice inflection that merits a look at the physical proximity of communicating with others.

I recently moved across the country, from Reno, Nevada to Gainesville, Florida. The move was not lightly taken, but was a huge next step in the life of my family. This left us with nearly all of our good friends and direct family 3000 miles away. We call our friends and family as often as we can, but to be honest, speaking with my mother and father is not the same on the phone as it was when we would go out to lunch and enjoy each other’s company for an hour. By no means am I saying that you should take a different coworker out to lunch every day, but rather making the point that the phone simply is NOT the same as looking at someone while they talk to you. I have also had many experiences where those 20+ emails went back and forth with no one really understanding what the other was trying to say, only for me to go physically stand in front of them and figure out that, in fact, we’re talking about the exact same problem and have more-or-less the same solution (obviously with some minor tweaks). The language of an email wasn’t the right mechanism to see the nuances of the conversation, so while I thought my idea was being attacked, the other person was using different terms for their standpoint and feeling like I wasn’t listening.

A former coworker of mine was constantly reminded that his language and tone of his email was unacceptable. Rather than adjusting his emails’ “tone”, he decided that it’d be easier to append a disclaimer to the end of his emails with rectification steps should his tone be considered inappropriate. Needless to say, eventually this disclaimer disappeared because the problem was never solved by simply having it there in the email. When you’d speak to him in person, you could see why people would see his tone as condescending and rude. He freely spoke his mind and had some sarcasm throughout the conversations with him, however, none of it really was rude. Back to the point at hand, the tone in his emails was the same, but without the lighthearted amusement that was included in his actual conversation, the essence of his discussions was lost and thought nasty.

Have you had an experience where a conversation through non-face-to-face means turned bad? Or perhaps, clarified matters in a way that speaking directly to them couldn’t do? I’m interested to hear!

I’ve already discussed that project managers are a necessary addition to a development team, as well as the fact that some are overzealous, which takes its toll on the team dynamics. Today I want to discuss why lazy project managers are actually terrible and destructive additions to any development team.

They don’t respond to information requests. How many times have you contacted someone with a question and not wanted to receive a reply? I’m not sure that’s ever happened to me, because generally I ask questions with the expectation of an answer. This is no different for project managers, and in fact, the majority of their job is balancing the plates up in the air while shuffling people toward the end goal. This requires providing INFORMATION when individuals need it. An engineer, artist, designer, etc. should not have to ask twice, or even three times for an answer that is relatively easy to obtain.

They come to meetings noticeably unprepared. I’ve been to numerous meetings where everyone arrives on time, is ready to contribute and discuss, and all that is necessary is the person in charge to get things underway. In fact, the project manager has that duty. So, the meeting begins, he/she then asks what needs to get discussed. Wait a minute, shouldn’t the purpose of a meeting be to have an agenda? A plan of action? Open ended meetings tend to be rather unproductive and useless, which is why we rely upon the manager of the project to get things focused. Not knowing where people are, what they are to do, or why the meeting was being held in the first place is a huge issue with productivity in teams.

The behave reactively, rather than proactively. A sign of any truly great person is their ability to see problems ahead and act on those before they become a problem. Lazy project managers, however, sit in their cubicles and no one really knows what they’re doing with their time. The idea is based on the knowledge that they don’t go out of their way to resolve issues ahead of time. Until YOU go speak to them, the issue doesn’t exist as far as they’re concerned, and in reality, once you leave their office, it gets shoved to the back burner for some YouTube amusement.

Are unresponsive unless 1. The boss asks, or 2. you go and talk in person. Everyone is interested in maintaining their job placement for as long as it suits them. This is a fact of the working world, so of course, when the boss asks a question, the answer must be somewhat forthcoming. With non-supervisor people, however, the communication channels tend to be more lacking. In fact, sometimes, the communication becomes non-existent. This forces the coworkers to actually go to the project manager with questions because they likely will never get answered via the telephone or email.

They destroy team enthusiasm and engagement. This is less a feature of lazy project managers, and more of a symptom of having one on a team. When a project manager is performing their duties to the best extent possible, they provide a level of cohesiveness to the team that is hard to obtain any other way. This aspect is removed, however, when the project manager is lazy with respect to their duties. The ties of comradery never fully develop, and in fact, many times are reduced to merely “having to” work with your team on some project that no one cares about.

There are some things I’m missing in the above list, however, these are the most problematic issues I have seen in my time engineering. Project managers can, and I would argue MUST, be the lynch-pin in any development project. Success or failure to launch lies significantly on their shoulders, and as such, they should be treated with reverence and respect so long as they get off their asses and do it.

Mind you, more often than not, the project managers I have worked with have been proactive and successful, but those that cause problems are the ones that stick out in peoples’ minds.

Today, I want to talk a bit about feature creep. Â First off, let me say that I’m going to be performing my own voluntary feature creep in this post by adding a podcast version and a video one. Â Take a look at the next post once it’s up and I’ll do a vid for the both parts (I was just getting long in the tooth by the end of this one).

Feature Creep

My programming friends, as well as most engineers I know, already understand the concept, but bear with me. Â Feature creep is a situation in which a scope document was created with requirements before the project started. Â Once underway, however, someone (usually at a higher level, or even a customer level) requests a new feature to be added. Â It may be fairly innocuous, or potentially larger in scale, but in the end, it is another feature that was not included at the beginning. Â One new feature really can’t be considered “creep”, now can it? Â Ok, so the creepiness comes from the fact that it’s not one, but generally, many new features requested, not included in the original scope.

Who Cares? Â That’s What We Pay Them For!

True, you (managers) pay your engineers to complete projects that need to be done. Â And also true, that those features must be super cool if you’re asking for them to be done. Â There are some problems with feature creep though, namely:

More time is required to implement new features. Â This sounds like a “duh” kind of statement, but for some reason, managers don’t seem to understand that fact. Â Obviously, the engineers are inflating work estimates anyways to get some more time for browsing the internets (yes I pluralized that for fun). Â I have found that in the majority of estimates, these kinds of inflations don’t occur. Â Engineers design the plan and work the plan, basing their estimates on what they really believe they can accomplish.

More time is required to implement new features. Â Yes, I repeated myself, but this point is slightly different. Â When new features are requested, the engineer generally NEEDS more time. Â This means that the time-table of the project SHOULD be extended. Â I have had so many situations in which features are requested that will take an additional week of work, and the project managers say, “We can’t push the date back.” Â If you go to the store and have just enough money to buy your deodorant, if you pick up a container of ice cream too, some milk and cookies (I’m feeling sweets right now), walk up to the counter and plop it down, the cashier will NOT let you take the items with only enough money for the deodorant that you likely forgot on the way to the ice cream! Â Just because you want more, does not mean you can have it just because you ask.

More requirements equal more money spent. Â Let’s assume that you can push the date out slightly for the new features. Â That’s great, but what are you really doing? Â You’re increasing the cost of engineering time, obviously, but you’re also increasing testing time too. Â Sometimes, seemingly innocuous feature additions can have some very interesting bugs attached to them. Â So not only are you increasing the engineering time for development, but also testing, bug fixing, and not to even mention documentation of the new features (I’ll assume your customer would want to know how to USE the new feature).

More requirements can impact system design and robustness. Â Not always is this applicable, depending on the scope of the implemented function, however, systems are designed to perform the tasks they need to perform. Â If you need a simple system that accepts employee hours and comes up with summaries for year-end reports, your design will be MUCH different than if you need a system that will be scalable to incorporate plugins for new functionality that may be needed in the future. Â Or, for example, if your system needs to handle a small amount of traffic by users, it will be designed with one particular database technology. Â If, halfway through, you decide you want to deploy it on a massive scale with millions of hits an hour, that database technology may be insufficient.

Are there more implications to feature creep that I haven’t mentioned? Â I’d love to hear your thoughts!

I recently read a post by John Hunter entitled, “Finding, and Keeping, Good IT People,” and couldn’t help but think it merited some additional thoughts on the subject. He makes a few main points in his post, namely: look at the hiring process, reduce your requirement count, treat existing staff well, and a good programmer is a good programmer. I’m going to expand on all of them here.

Look at the hiring process

Your hiring process is intended to filter out the large number of applicants into a small pool worthy of interview. How this process is implemented can turn good engineers off from of a job simply because it is not robust enough to handle the applicants that apply. Continue reading “Hiring and Keeping Good Engineers (part 1)”→

So now to the final discussion in my series. About Great engineers! I have been pondering this one, because, for some reason it’s the hardest to provide valuable information about. Great engineers/employees in general are hard-working, deadline-meeting, project-churning machines that bring value to your organization consistently with a smile on their faces. What could be wrong with that?! I’ll guess that nothing is wrong with that, though there is the matter of keeping them as great engineers. Lack of motivation, disinterest in doing the same ol’ thing, frustration with other engineers, and many more daily occurrences can push their productivity down. So for a manager, your job is to ensure that they are happy and able to do their duty!

So here I’ve been sitting, contemplating how to write this post, and not having any epiphanies as to how to go about it. Shy engineers are easy to discuss, assholes are equally easy. Ineptitude was a bit ranty, though in my defense, those engineers tend to rant of their own accord, so it seemed to fit. Now comes the one that should be easiest to write, but is hard to really come up with something intriguing and useful. So I’m just going to throw it out there for the record, because this is the category in which MOST engineers sit, and the reason engineering actually works in companies. I’m going to refer to them as A+ Engineers because if they were in school, I’d tend to give them all A pluses for grades.

In the world of business, you can look at required tasks several different ways. At the largest scale, you can look at how a company’s stock price fluctuates with organizational decisions, ROI, Resource management and supplier/customer relations. Each area you turn to, there are many different components which aggregate into the whole. You can keep going further down until you finally hit those workers who are doing the seemingly menial tasks that must be accomplished in order to get the answers you (the manager) need to have in order to perform your job satisfactorily.