Promoted to Project Micromanager

Unless you started your career as a project manager, you most likely have to work your way into the position. You probably had a highly technical role as a software engineer or maybe a systems engineer. Whatever your role was, you were the person actually doing the technical work. In my world, the world of software development, many software engineers find themselves being asked to take the role of project manager.

First let's understand why you, an engineer, have been asked to take on the role of project manager. You have probably gained a reputation of being organized. You write solid high-quality code that passes all requirements. Your design documents are well written. You stay current with the latest technologies and methods of software engineering and you know when to apply them. You are known for finishing your software tasks on time and help out other engineers when requested. You have demonstrated that you have strong technical skills and you are a technical leader.

Now you have been asked to manage the next development effort as project manager. It makes sense to most people. There is a new project, someone needs to manage it. Why not appoint one of the best engineers to the role? It's an opportunity to grow and to enhance your skill set. It will be a career development opportunity. Makes sense right? Well, maybe… Project management does require a new set of skills that are not required as an engineer. Many of these are obvious. Scheduling, budgeting, and tracking the progress of work are all project management skills that can be taught and understood by a smart engineer pretty quickly. But the hard part of this new role is realizing YOU ARE NOT AN ENGINEER ANYMORE! ...well at least for this project anyway.

Here is why this can be tough. The number one talent that you have relied on in your career has been your technical abilities. Because of this, you will find yourself wanting to exercise these skills. During the project, technical challenges will pop up and your first reaction will be to jump in and solve it. DON'T! Let the engineers on the project solve them. It's their role now, not yours. Your job is to make sure they have all the resources and time to solve it. There is nothing worse as a software engineer than to have your manager telling you how to write your code. But that's exactly what can happen in these situations.

Utilize Empowerment
So how do you keep yourself from becoming a micromanager? The best technique I use is empowerment. There is no empowerment algorithm, an empowerment Java package, or an empowerment eclipse plug-in. You’ll have to step out of your technical mindset to understand and implement this one. Empowerment can be a tool for motivation and for delegation. On tough projects you need a team of people who are motivated to take on hard problems and to put in the effort needed to get the job done. You can’t solve all of these problems yourself. You don’t have time. So you will need other team members to work on them. Here are a few ways to empower your team:

1. Get them involved as soon as possible. Make sure the engineer estimates the durations for his or her own tasks. If they said a task will take three days, they will put in more effort to make sure they meet their own goals. If you set the task duration to three days, then their extra effort would be to meet your goals. And people like to achieve their goals, not yours.

2. Don't second guess their opinions. The engineer has been heads down in the problem. Trust their opinions. If you even slightly show mistrust in their opinion the problem and the solution becomes yours. Each time your opinion gets implemented, it becomes more your task and less of theirs.

3. Don't start tasks for them to finish. I once had a manager write the JavaDoc, define all methods, and parameters for me to help save time. He then expected me to fill in the code in each of his methods based on his documentation. I second guessed myself every time I had to change anything he did. I must have visited his office twice a day asking him why he chose to do things the way he did. The point I'm making here is when you start a task for someone, you become the expert and they will come to you to make decisions.

One of the main ideas in empowerment is the idea that people like to fill needs. When it is made obvious that no one else is the owner or expert in an aspect of the project, the person working those related tasks will take it upon him or herself to master those tasks. Your engineers will step up and fill the needed role. It becomes more gratifying to them knowing they mastered the challenges themselves and are not the expert.

Making the move from engineer to project manager can be exciting and a learning experience. If keeping out of technical issues is something you can't resist, then think of it this way. Upper management originally chose you for the job because of your technical leadership. Making sure your engineers are able to show their technical leadership will give upper management new candidates to manage the next project and you can go back to being an engineer.

Shook Labs Android App

We just launched our new Shook Labs website. With the holiday shopping and all, we didn't have time to put too much into it. The site does give more insight into our Android App. Check it out at www.shooklabs.com.

New Android App - coming soon

Michael Cook and I put up our two second teaser website for the Android App we are developing for Google's Android Developer Challenge. We Decided to give ourselves the name Shook Labs (Sheeley + Cook = Shook). We also came up with a slogan "When you at?" We're not sure if we’ll keep the slogan though.

We are starting to get excited about our idea. I wish I could say more about it but I've been sworn to secrecy.

Android Developer Challenge

As many of you already know, Google has launched the Android Developer Challenge. The challenge will give away $10 million dollars in awards for "great" mobile apps built on Google's Android platform. Being the past founder of a mobile applications company, I could not resist. The ideas started flowing and after several brainstorming sessions with a colleague of mine, we came up with our "great" mobile app.

The colleague of mine is Michael Cook, past founder of CookWare, Inc. At this point, all we have are a few requirements documents, a slide show, and a basic Android "hello world, testapp" application. I never expect much when entering challenges like this, but who knows? Wish us luck!

Chasing a Constantly Changing API

I was once waist deep into a development effort when a partnering development team informed us that they where changing their API again. The component we were developing depended on their components for data and capabilities. We had spent time interfacing with their component. We had been careful enough to isolate the interface to their API by creating a façade. This way, the two components were decoupled as much as possible and our component was somewhat isolated from future changes to the partners API.

Our partner was already changing their interface. Not a problem, right? The façade is the only subcomponent affected by this change. An engineer spends a few days reworking it and we move on. It’s that easy right? Well, no.

When this happens you need to make sure you find out why their interface is changing. Ask your partner why this change has been made and why this change was not thought of originally. If they do not have solid reasons for this, then be assured that their API will soon change again and you will find your team spending another couple of days updating the façade. I have seen this situation play out many times. Each time the partner swears that "this is the final change to the API" only to have it change again a week later.

Yes, the façade acts as a buffer to new changes but changing the façade still requires work. And no façade is completely perfect. Some changes might still bleed into other subcomponents causing many other needed changes. In fact, the more you need to update the façade, the greater the chance that the changes will effect all the subcomponents who utilize the façade.

In many situations you have no control over your partner's development practices. It is important to first identify when you may be dealing with an unstable API. Once you have identified the API as unstable, you have a few options other than using up all your resources chasing it.

1. Hold off on making the changes. Wait a few weeks before updating your façade to their latest API. You might also be able to wait till the end of the development effort to make the update. This way, you will skip a few interim API changes. I do have a word of caution on this. Make sure you’re not ignoring their changes; only skip the updates to your code. You want to make sure their changes do not drastically change or remove the needed data or functionalities you require from them. If you wait till the end of development, it might be too late to address the problem.



2. Send you partner your façade. Many partners will pushback on this. They might see this as more work for them, but it might actually save time for both of you. They have a better understanding of the new API and it will be a quicker change for them to make. They already know what changed in the API and why, thus cutting down on cross team meetings and emails.

Make sure you identify their unstable API as a risk to the project as early as possible. Assess your options; determine if your schedule, budget, or scope for the project is at risk. Chasing a changing API never seems like a big deal to the project until it is too late. If it is not identified and dealt with early then it will put the whole project at risk for failure.

Engineers and Marketing Myopia

For those who are new to SheeleyTech, I am a software engineer at heart but more often I “act” as a project manager, product manager, and systems engineer. Because of this, I tend to find myself in a conflict of interest that, if I’m not careful, results in marketing myopia.


“Heads Down” Versus “Heads Up” Roles

The engineer’s role
Engineers love to learn and apply their newly acquired skills. They enjoy building products by using their knowledge, skills, and past experiences to design and create solutions. A large part of this enjoyment is the challenge of creating the product. Sometimes it is the ability to utilize a technology that the engineer has never used before. As a software engineer I can look back at the software products I enjoyed developing the most. There is the first time I used CORBA, or the first time I used RMI, or learning about and developing web services was a great experience. Keeping up with the latest technologies, gaining new skills, and creating products with new tools requires the engineer to focus on the development of the product. I refer to this as a “heads down” responsibility. The idea being that the engineer’s head is facing down at the computer screen writing code or reading about new technologies.

The product manager’s role
When you are in the role of product manager, systems engineer or even the project manager you need to be focused on the customers’ problems. What needs do your customers truly require? Your job is to make sure you are building a product that solves their problems. You need to be what I call “heads up” – researching competing products, learning about the customer, and gaining feedback from the customers. This process does not stop once the development effort of the project begins. Challenges and issues will come up during development. Decisions will be made halfway or ever later into the development of a product that will have a huge impact on the final product. These challenges will come from the development effort (technical issues) as well as from the customers (market issues). Both of these types of challenges need to be addressed with the interests of the customers first.


The Conflict of Interest

When the same person developing the product is the same person who is responsible for making sure the product will meet the customers’ needs, there is a natural conflict of interest. I speak from experience.

Once the development effort starts, the engineer begins to fall in love with his or her product. There has been long hours invested into their development. Thus the engineer has been “heads down” and the focus has been on the product. When technical issues come up, the first reaction is to find the best technical solution to the problem. This is how the engineer wants to solve the problem. Because the product manager and the engineer are the same person, the interest of the customer can get lost. For example, a drill bit engineer (if there is such a thing) will focus on the drill bit. The engineer begins to think that the drill bit is the focus and that the customer needs a really good drill bit. This is wrong. What the customer truly needs is a hole, not a drill bit. Issues need to be addressed by thinking about the need of a hole, not how to make the drill bit better.

If you share roles as an engineer and as a product manager, you need to spend equal time “heads up” as well as “heads down”. If you started your career as an engineer you need to fight your instincts to focus more on the product than the customer. Before dealing with any technical issue, take a step back and think only about the customers’ needs. Review any relative requirements created for the product. Revisit use cases and all the materials you created before you put your head down into the code. Seek out subject matter experts or even contact the customer to get their perspective on the problem. This way, in the end, you will have developed a product the customer needs rather than just a product you enjoyed developing.

Verizon FIOS in the Sky

It’s a quiet Sunday afternoon. I’m reading an operations management textbook on the porch while my wife is off running errands. It’s a typical Sunday afternoon, until I see a plane carrying out a mission overhead. This mission is directed at a small box located approximately 7 feet from where I am sitting. As the plane circles around the route 128 area near my home, I can’t help but think about the battles being fought over my cable box. Only a few months ago I switched from Comcast to RCN. RCN had mailed me a flyer advertising their much lower priced cable TV service. I looked into it and could not see any reason not to switch. $20 a month cheaper, all the same channels, with the addition of DVR. So I switched. RCN won that battle. Now up in the sky is another company jumping into the fight, Verizon.

Verizon FIOS TV aerial advertisement over RT 128

At first I find this all a little odd. Here are large companies all fighting to be the provider of my cable television service. They are spending large sums of money, sending sales people door-to-door letting people know FIOS TV is available in the area, paying for aerial advertisements, setting up FIOS kiosks in the mall, visiting local businesses and giving out FIOS basketballs. I also get flyers in the mail almost daily from Verizon, Comcast, and RCN. Meanwhile, I am just looking out to see who is cheaper.

To me it seems they are all in a market where price is the main differentiator and just over the horizon most content will be available through the internet anyway. I know these companies realize this. So, it really makes me wonder why they are so eager to invest in, and enter into, the cable TV market. Shouldn’t they just be focusing on the internet market? It seems to be a no brainer that in 5 to 6 years from now all broadcasts will be through the internet. Customers will soon only require internet access.

Maybe these companies see cable television as a loss leader for future internet subscriptions. Currently television packages can be bundled with internet service. The fight to be my cable provider might actually be their chance to be my internet provider. When television is available through the internet and consumers realize they no longer need a separate TV service, these companies will not care. We will have become their internet service customers. If I’m right, look for your monthly cable bill to drop and the internet service to increase. This way when you drop your cable service most of your monthly payments will be tied up in your internet service anyway.

As a customer it’s hard to tell what the long-term strategy is for these companies. But enough of this, I need to go checkout the prices for Verizon FIOS TV.