You may have the greatest ideas on the planet, but if you can’t communicate their worth, no one will adopt them. Not always is the problem that your ideas are the best, however, and so I’m going to describe a few reasons why your “great” ideas dont get adopted. Continue reading “Project Managers Don’t Listen To Anyone’s Ideas”
I have worked on many projects in my time as an engineer, and in that time, I have discovered that the project manager tends to be one of the lesser liked roles in the project team. In my previous post, I discuss the reasons why project managers are critical to a project’s success. However, despite the positive sides of project management, engineers, specifically, seem to experience both the overzealous and lazy project managers with a high enough frequency that the major complaints must be voiced. Therefore, here are a few of the major points of contention with overzealous project managers and what you should do about them: Continue reading “Overzealous Project Managers: Problems and Solutions”
In my prior post, Beware, Feature Creep Has Downsides, I discussed the implications of feature creep that would be of concern to managers in relation to time and money expenditures. Â I’m going to delve a little bit further here to discuss employee engagement and something to think about for managers out there. Continue reading “The Dangers of Feature Creep”
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).
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!
Update: Check out the sequel: The Dangers of Feature Creep
You’re an engineer. You are smart. You know it. And you show it to others in degrading and nasty ways. Since I started this blog, I have chatted with several people in the comments about how many engineers and highly analytical workers seem to treat non-tech workers as though they have little to no intelligence in technical matters and therefore can be spoken down to.
I implore you, help me fix this impression!
As an engineer, your job is more than merely writing code. It also entails the more subtle social interaction with your team members to get your product designed correctly, funded, marketed and deployed. If your project manager doesn’t know much about the technical side of matters, try to help them understand! Give them a little bit of background as to why some part is taking longer than expected. By treating them with disregard, you are weakening the image of engineers as well as reducing their desire to know what you’re doing.
This can lead to steamrolling your bosses into getting you to work faster, or even just making unrealistic promises to customers because they don’t have the information they need! A short time of explanation can actually save you frustration at being pushed around.
Just as they don’t understand your side of the situation, you probably don’t fully understand their side either. How much knowledge about advertising or selling do they have that could be of use to you in the future? A mutual exchange of information can lead you both to better levels of understanding, and make you both better members of the team.
Again, I implore you, fix this situation! Push yourself to move beyond the belief that people can’t figure out what you’re doing and make them understand!
Why do you think engineers tend to disregard ignorance, rather then reduce it? What options are there for those non-technical people who need help? Let’s discuss in the comments!
I presently work in an environment ripe with regulation. The gaming industry (and by that, I do not mean video games for WoW players, or XBOX) is the most regulated market in the world. More so than even health care, in fact. As such, one of our largest points of contention revolves around regulators. These regulators are not one cohesive body, but rather, different entities in every different jurisdiction around the world. This poses some interesting problems with respect to how engineers and managers design products for release. Continue reading “Dealing with Regulators and compromise”
And so begins the second half of the post. If you want to go back to read the prior half, please see Hiring and Keeping Good Engineers (part 1)
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)”