Make time for your direct reports

During this time of year when next year’s annual operating plan is being crafted and you’re looking at your sales trying to meet full-year estimates, now is a more important time than ever to be meeting regularly with your direct reports.

I prefer a cadence of every-other-week 1-on-1 meetings with direct reports. Your mileage may vary depending on number of direct reports, geographic location, etc.

Commit to a schedule

Whatever you do, when you schedule these meetings with your direct reports, don’t reschedule them, and reschedule them, and reschedule them.

Nothing says “this conversation is not important to me” more than a meeting that repeatedly gets pushed back days or weeks after its originally scheduled day and time.

Depending on your position on the organizational chart, there may be a lot of preparatory work that your direct reports go through prior to a 1-on-1 meeting. Your availability may also be a premium, so your direct reports may queue up important discussions for that 1-on-1 session where they have your undivided attention that they would otherwise not be able to get.

Fish or cut bait

If the meeting is destined to never actually take place, then don’t bother setting the expectation that you will meet in the first place — it’ll save time for everyone.

During this time of year especially, when everyone is busy, make the time to invest in meeting with your direct reports. After all, they are supporting your objectives and ultimately make you successful.

Post to Twitter

Tags:

Related posts

A lesson in client servicing an application development project

We recently completed our first integration with an external customer website and our e-commerce website. (By “integration,” I mean an API in which we pass configured product data from our site to a 3rd party shopping cart.) What ensued was an interesting learning experience for myself and our group of developers on the project.

Everybody has their own development process

Standards are hard to come by in the web application/development world and the process for managing development projects is certainly no different.

Case in point: We created a technical specification for an API and worked with developers on our own team spanning 3 different time zones. Add on top of this that our technical specification was an “ideal world” document which didn’t account for specific requirements of the external website we were to interface with. This meant further coordinating our simultaneous development of our API with the integration of the API (as we were building it). This essentially equated to “building the plane as we flew it.”

Agile development is great…but falls flat on its face when involving people outside the core team

In an agile software development world, code is written, tested, and released in several mini-stages. This methodology allows for us to be very open, flexible, and speedy with new development on our various web properties.

However, my takeaway from this project is that I would utilize a different approach when interfacing with external developers that are not part of the core team…taking me back to my agency roots when educating our clients about “our process.” What we found is that our process didn’t at all align with the customer’s process for development, testing/QA, and release management. In fact, it caused a lot of tension between the two groups throughout the project — especially in the home stretch.

Where we normally operate in a lean environment with small release gaps and short testing periods, the external party we interfaced with was accustomed to a more traditional waterfall model of building the entire application up front, test all of it at once, and going through several iterations of testing & debugging of all code at the very last stage.

Lesson learned: Provide a visual map of your process and timing

Multiple lessons were learned on this project:

1.) Provide a “site map” of the intended integration. This allows business stakeholders to visually understand where the API “handshake” occurs between the sites. It also empowers the external QA team to understand the bigger picture so they can see which areas need testing.

2.) Provide a map of the major components of the development project, timing on each, and the order in which they will be developed. Seems simple, but when you don’t manage the external developers, keeping tabs on the timeline proves difficult.

3.) Schedule regular daily meetings to check in on status and even if there’s no updates to report, it provides a crutch for the collective team to lean on so everybody remains on the same page (in terms of timing & expectations). Morning meetings are important so the day doesn’t get away from either party. This is particularly helpful in the final weeks/days of the project.

Post to Twitter

Tags: , , , ,

Related posts

How to determine if you delegate enough

rescuetime-logo.jpg

I recently came across an article that really hit home for me. It’s titled “How to determine if you delegate enough.” To quote the article:

How do I know when I am delegating enough? I think that the answer is very simple: You are not delegating enough if the questions that you are getting are easy for you to answer.

If your subordinate comes to you with an easy question … the possibility is that the answer was indeed simple but you didn’t share the necessary information, requiring the subordinate to ask the question. This may mean you retain some information in order to feel that you have not lost control, but it causes your people to be frustrated and to feel that you don’t trust them. It’s important for you to disclose to your subordinates all of the information that they need to do their jobs.

Shifting from “doer” to manager & avoiding “doing nothing” as a manager

In my recent role change, I’m now managing a larger range of projects and a larger group of people. I’ve always admired managers and executives who could get their hands dirty. I think this garners respect and establishes credibility with any manager. In this new role, my biggest challenge is identifying the tasks to take on myself and to delegate to my staff. While there are many simple projects and tasks I am perfectly capable of handling without the help of my staff, I need to be able to identify which tasks make the most sense for me to be focusing my time on.

Enter RescueTime – How I measure where I’m spending my time

I recently came across a new free service called RescueTime. It’s a web-based service with Mac and PC “listeners” that install quickly and effortlessly so I can monitor my application usage and website visits. The benefit here is that my “doer” tasks vs. my “management” tasks are clearly divided between the websites and applications I use:

  • For example: firing up the Mac OS Terminal app and hopping on a server to move some files around is clearly a “doer” role. I file the “Terminal” app as a “development” task/app.
  • On the other hand, reviewing Omniture web analytics data is most definitely a web marketing role, so I flag all Omniture sites as “web marketing” tasks.
  • Email, Excel, Visio, Microsoft Projects are all tagged as “eBusiness” applications.

 

The RescueTime Dashboard

Since I have a dedicated laptop specifically for work, the only time I really use it is for work-based functions. Since the RescueTime “listeners” time out after 2 minutes of inactivity, the service provides a very accurate portrayal of the true time spent working (for me, at least). Of course, when I’m in meetings and the laptop is idle, this “work time” is not captured. Since the majority of my job involves a computer, it’s pretty safe to say that it captures most of my work-related activities on any given day:

 

Below we see (for the week of March 30th) I spent 55 hrs and 50 minutes working.

 

Below we see how my 55 hrs and 50 minutes that week broke down into the “tagged” sites and applications I used:

 

RescueTime then tells me how efficient I’ve been based on the above data collection and my account settings (I rate “ebusiness” as more efficient than “development”):

 

I’m still spending too much time “doing” and not delegating

When logged into the RescueTime dashboard, you can hover over the above red bars to see the total time spent on the tags. “development” was comprised of more than 11 hours of work. That’s 20% of time dedicated to “doing” which is much too high. RescueTime has also calculated my efficiency. Efficiency is described as:

A score based on the ratio of productive activity to distracting activity. To improve this, spend a higher percentage of time on productive tasks.

Without the RescueTime software and web service, I’d have no way of quantifying this information other than going by gut feel.  Now that I know I’m spending too much time, I am not worrying as much about being perceived as a manager who doesn’t like getting their hands dirty. RescueTime is enabling me to focus on more accurately managing and delegating the tasks and projects for my staff.

Post to Twitter

Tags: , , ,

Related posts

Relationship Management vs. Project Management

What percentage of your time is spent managing projects and what percentage of your time is spent managing people?

As a part of ongoing career development at our organization, we have the benefit of meeting with an outside consultant specializing in coaching leaders, managers, and product teams. The end-goal is to broaden your horizons in the way you approach critical thinking situations related to internal projects and consumer-facing products (ultimately within the team or business unit you are part of).

Relationships management is different than project management
In my one-on-one discussion today, the question was posed to me: What percentage of your time is spent managing projects and what percentage of your time is spent managing people? After I thought about it for a minute, it dawned on me that the majority of my time is really managing relationships, not projects. This doesn’t necessarily equate to direct reports who you “manage,” but simply people/piers who you interface with on projects. It’s an important distinction to make because relationship management is considerably different than project management.

Relationship Management in a large organization
My previous job was at a small business with less than 25 employees (where I worked for nearly 8 years). A larger corporation is different in that you have to deal with a larger number of people (and personalities) to the point where you are focusing on relationship management more than anything. To get any large-scale project done (like a consumer e-commerce site), being able to work with the various departments the website touches is a critical component to success. Taking that a step further and understanding other departments is an important component to relationship management and what separates it from project management.

Managing Relationships is Good for Business
It’s interesting viewing the different styles of project managers in any business. Some are focused exclusively on the tasks of the project and at the end of the day, they measure themselves on their ability to complete those tasks regardless of what it took to get them done. I have seen this lead to major bridge-burning and damaging relationships with individuals/departments. While this may not affect the short-term health of an organization, it certainly does affect the long-term health and the ability to effectively work with each other.

Others are focused on getting what they need to get done while building relationships with other people and departments. Because when it comes down to it, you will probably need their help again in the future. Guess who’s going to be more responsive to helping you out or going that extra mile for you — the person who you steamrolled to get your project completed, or the person who you developed a relationship with? I know I am more inclined to help someone who will return the favor down the road.

Tying it back to online strategy
As online strategists, marketing managers, and even web developers, it’s important for “us” (I group “us” together as the people that build/manage/maintain/oversee websites) to communicate what websites can do for the company and develop relationships with internal departments so they keep the website top-of-mind.

A business that operates with the website top-of-mind values the efforts of the online team by viewing them as a strategic department, rather than a cost center. Strategic departments have the perception of adding value to an organization. Cost center departments have the perception of costing the organization money. Operating under the umbrella of “strategy” is much more healthy (and fun) for everyone involved as opposed to a “cost center.”

Post to Twitter

Tags: , ,

Related posts

Positioning yourself as a “go to” person for your department or team

Recently, a post on the CIO advice and opinion forum posed the question about working your way up the IT food chain. This made me think more about advice for IT, developers, and general “tech” people and how they can break the mold of IT and advance up the department ladder. Some developers or engineers find themselves working for managers who “have no clue.” What they don’t realize is the managers have the ability to work with internal stakeholders effectively and translate business problems into requirements for the technical team to implement.

Here are some examples of how you can position yourself more effectively with other departments in your organization so they look at you as the “go to” person not by just the title on your business card, but by the value you bring to their business functions.

The title on your business card defines what you do, not how you do it
The title on your business card does not always mean you are viewed as the “go to” person for your functional area — I have experienced plenty of people in business who are avoided at all costs due to lack of strategic and/or big picture thinking within an organization or on a project. Your title defines what you do, but how you go about doing it is another game completely.

In IT, understanding the needs of another department is extremely important when they come to you with a question or request. Nobody likes feeling stupid, and this is one area where IT typically falls short — fail to understand the problem, provide short, non-descriptive answers to questions, and allow the uneducated business person to craft the design requirements for a (web) project that makes little sense. This then results in an application or solution that underdelivers due to poor planning and creates a customer (the employee in the other department) who is unhappy.

Picture yourself bringing your car to a mechanic for service…how do you want to be treated?
(This is often times an easy analogy to make, so if you already understand cars, then pick another area where you are not as knowledgeable in and put yourself in the position of that customer.) You drive your car into the shop — it’s vibrating whenever you “drive it” and you obviously want it fixed because A.) it’s annoying and B.) it seems very unsafe!

Now, there are two ways to approach this: probe deeper, ask questions to help you navigate the troubleshooting process with the customer face-to-face, or take the car and run a series of tests that run the risk of looking at an area of the car that is not broken (and in the end not be able to find anything wrong — we’ve all experienced this, and it’s frustrating!). Vibration in a car can be a number of things — bad brakes, unbalanced tires, unbalanced driveshaft — the list goes on, and can be varying degrees of technical explanation depending on the customer’s expertise on the matter. A “go to” person asks questions because they genuinely want to help.

Sometimes the problem described is not the source of the problem at all
Odds are the customer doesn’t know exactly what the problem is, but they may suggest a fix because they don’t want to appear stupid in front of you. This happens countless times in business! They could say “the tires feel out of balance” but in reality, it could be that the vibration only occurs during braking, which generally points to warped brake rotors (among other things). Being the responsible businessperson you are, you would always start this process by going back a step or two to understand the customer’s needs and a description of the problem.

This will ultimately lead to a more accurate and timely resolution to a problem and a solution that hits the nail on the head. Part of being the “go to” person is providing that guidance that other departments lack — knowing they can come to you with an idea and you can help them make the most of it without making them look incompetent is critical in business. You will turn them into repeat customers.

Your customers (fellow employees) don’t really care about your deadlines
Another problem area in IT is the ability to turn on a dime or the tendency to paint a dreary picture from a resource standpoint. Just like bringing your car to the shop, you don’t really care to hear about all of the other work the shop has queued up, so spare your own internal customers (fellow employees) the details. Explain that you want to help them, understand their timeline, and fit their project into the mix where you can. If you make other departments feel like you’re doing them a favor for every request they come to you with and that it feels like pulling teeth just to get some time, you will lose your position as the “go to” person. Likely, they will look elsewhere or even outsource — at which point you’re cut out of the process completely.

A “go to” person follows up.
Ever brought your car to a mechanic, the expected due date comes and goes, and you never hear from the service manager? Avoid this situation at all costs. Manage your customer’s expectations, and provide reasons for why you’re going to be later than promised. Things happen, deadlines change, but how you manage the situation will also improve the satisfaction and perceived value you bring to a project and will ultimately paint you as a “go to” person. The “go to” person gets things done and follows up when they have or haven’t been accomplished. It’s just that simple.

Work through the process and/or problem, don’t work around it or point fingers
Many times IT is looked at for solutions to sharing data or information with other internal departments or external customers. This often times means creating a new process for the application or implementation you’re building on behalf of a department. If the success of your project implementation depends on the actions of another person or department, then work with them until their job is finished. Unless explicitly told to do so, don’t “pass the buck” and assume your work is done when another department has to get involved. Part of being a “go to” person is finding the answers to problems that are outside of your current knowledge or your functional area’s expertise.

Your internal customers may not realize the amount of collaboration involved, so don’t hesitate to give them a high-level (notice the phrase “high level” — avoid the technical details!) overview of what’s being done throughout the project. This is what will make them look to you in the future for other projects and view you as a “go to” person.

Post to Twitter

Tags: , ,

Related posts