Browsed by
Author: The Mindful Manager

Both Sides: Software Schedules

Both Sides: Software Schedules

I’ve been on both sides. I’ve gone from being a first-line manager, then back to a developer. Then a director, then back to a developer. Then a VP, and yes, then back to a developer – which is what I am now, a developer.

One of my observations of the differences between developers and managers is how each views software schedules. Managers want schedules. They want them to show progress on the software. Sometimes their compensation is tied to major milestones in the schedule. Sometimes they want to show their boss/manager how good they are at managing by driving their teams to finish the software as quickly as possible. I get the pressure of showing progress. As a manager, if I didn’t show progress via a schedule with major milestones, I would definitely receive a poor performance rating.

On the developer side, schedules are arbitrary especially if it is an entirely new product. How can I know when it will be done if I don’t know everything required to create this new product?

Take, for example, the application I am working on now. It’s totally new. There is no code base I can leverage to get things up and running quickly. For new features that require API’s that I haven’t used before, I have to read up and understand how to use them in the new product’s code base. Then I have to consider the design and design patterns to use so that I don’t write spaghetti code. Well, I could write spaghetti code but I will only suffer when I need to add a new feature or I find I need to provide an API between subsystems. I try to set milestones but I sometimes miss them because of unfamiliarity with an API or a needed design feature.

However, I also find that if I don’t have milestones defined, I procrastinate. Maybe I should watch one or two more WWDC videos on whatever topic so I really understand how something works. Or, I don’t remember a particular algorithm that might be more efficient. Better read up on it! I find in the absence of a schedule, I wander a bit from the work. I could argue learning is always beneficial, but I find I can really take it to an extreme.

So are schedules good or bad? I’m neutral on it. As a developer, I think schedules can help me stay focused. But the schedule often doesn’t include time for things that are unexpected, particularly if it is a totally new piece of software. As a manager, I want to know the team is making progress on the software. A schedule helps me to see that progress.

Is there a way to balance these two views? I think there is. Both the developer and manager must consider the other’s needs. The developer requires time baked into the schedule to learn and to write good software. The manager supports this by creating milestones allowing for learning and for the unexpected. The manager does not go crazy if milestones aren’t obtained, however, the developer clearly communicates why milestones might be missed – and does so as soon as possible before the milestone arrives. Missing a milestone should be for good reasons. For me, I need the focus milestones provide. None of this is perfect. But developing software isn’t a perfect process with a checklist. Yes, as a manager I’ve had those checklists, but it didn’t help complete the software any faster.

Give and take is needed on both sides when creating a schedule. Both sides have to sign up for constant communication on the progress of developing the software and any unexpected issues that arise.

Give and take + frequent communication = creating software schedules that work.

Asking for a Raise

Asking for a Raise

As a manager, I’ve had many people over the years ask me for raises. Some people are very comfortable asking for raises and others are very uncomfortable. The ones that are comfortable usually approach it the same way. After a successful project in which they were a key part, they ask me for feedback. My feedback is usually good, and so they then say they think they have really gone above and beyond what was required of them and they give supporting examples. Then they ask me if I agree they had gone above and beyond what was required of them. If I respond yes, they ask for a raise. They are negotiating from a position of strength.

What they have done is made me an active participant in justifying a raise for them. Brilliant!

Then there are those that aren’t as comfortable and stumble through the ask.

What Not to Say When Asking for a Raise

Please don’t tell me that you accepted a lower salary and it’s been 6 months since you were hired and you think you need a raise. That just tells me that you didn’t think you were worth asking for more during original negotiations. Much better approach would be the above example.

Don’t start out with, “I’ve asked some of my friends that work at other companies what they make and they are all making $20,000 more than I.” My response will be, “You are paid exactly what others are paid at your job level within our company.”

If you think you aren’t being paid what others in the group are making, best approach it as a discussion around your current skill set and value to the organization. Again, using a successful project in which you were key is a good way to start the discussion.

The above examples of what not to do are examples of negotiating from a position of weakness. Instead, you want to enlist your manager in advocating for your raise. You want to negotiate from a position of strength.

By using a successful project and explaining how you were key in its success and how you performed at a higher level, you get me to either agree or disagree. If I agree and then you ask for a raise, I have to consider it. After all, I did acknowledge that you were key to the success of the project. Always come from a position of strength.

Company Values: Actions Speak Louder Than Words

Company Values: Actions Speak Louder Than Words

If you’ve ever worked at a small startup or have been part of a management team, you’ve probably worked on defining the company values and goals. Many employees are often cynical about the company values. They think it’s a futile exercise because it often seems that once the values are identified and listed on a company webpage, they are promptly forgotten.

Some values frequently selected include:

  • Integrity
  • Respect
  • Diversity

These are all good words. But how are those words implemented in the organization? Or are there implicit values that are actually implemented?

For example, many companies say they value diversity and integrity. However, actions always speak louder than words. If diversity is valued but the management team is composed entirely of white males, that makes me go “hmmmm.” Do they really value diversity? Or, say the company gets called out for not treating employees fairly. Is integrity really a value?

Why do disconnects occur between the values written down and the values demonstrated by the leaders and employees in a company? It’s simple: it’s the leadership team. The leaders allow certain behaviors to exist and flourish in an organization even if these behaviors directly contradict the stated values.

Employees take cues from the leadership team. If at an all-hands meeting, a leader jokes about “bro” culture, she or he is sending a signal that the “bro” culture is ok. Sure, it’s a joke. But why make such a joke? If a leader only considers hiring white males, how much does that leader value diversity? The managers in the company will take notice and follow that lead.

At one company for which I worked, one of my employees was having issues with someone in another group. The person’s behavior toward my employee was threatening. When I went to my peer to discuss the situation with him, he brushed off my concern by saying that was just the way this person was. Regardless, the behavior was inappropriate. I asked my employee to keep a record of what this person said to him. He did.

I took this evidence to our Human Resources department and they followed up on it. Found out this inappropriate behavior was happening with other employees as well and that it had been going on for awhile. People were afraid of the guy and avoided him. Hostile working environment anyone? The person was fired.

The reason this had gone on as long as it had was because the leader of the organization, by ignoring the inappropriate behavior, was supporting it. It didn’t matter one of the company values was respect. He was encouraging disrespectful behavior. His reasons for not addressing the issues were: “That’s just the way he is” and “but he’s a valuable member of the team.” These are never justifications for not reprimanding or even firing someone for inappropriate behavior.

Defining values for a company or organization is important. But what’s even more important is having the leaders of a company understand they are the ones defining values every day through their words and actions. Living the values is more important than just listing the values on a company webpage.

Communicating Clearly and Concisely

Communicating Clearly and Concisely

Leaning forward across the table, I explained how I was writing a blog about management and leadership. The man sitting across from me had an impatient look on his face as he shook his head and said, “So you’re writing blogging software?” I said no, I wasn’t writing software to create blogs, I was writing a blog about management and leadership. He waved his hand in the air as if to dismiss this notion and said, “That is not a business. You need to have a clear idea.” I attempted to share that I realized it wasn’t a business, however I wanted to write a blog about management and leadership. But he wasn’t listening. Looking into his eyes, I could see he was already thinking about what he wanted to say next. He only wanted to talk about his ideas.

There are two things that stood out in this conversation for me. One was that I don’t clearly explain what I’m doing which is something I can work on. Second, this person wasn’t listening to me.

The more I thought about this experience, the more I realized if I am going to communicate an idea or project or anything to another person, I need to have an absolutely clear, concise, and compelling way of doing so. Because no matter what I am doing or where I am working, I need to communicate about what I am working on whether it’s a product or a service. If I can’t do that in 1 to 2 sentences and it doesn’t sound very interesting, I’ll lose a large chunk of the listening population. Why? Because they will only listen long enough to determine if they are interested in what I am saying. Once they determine they are not interested, they aren’t going to listen to anything else I say after that.

In the last year, I joined a small business networking group to see how this type of networking works. Every week, each person has 30 seconds to introduce themselves and their companies. This was a tremendous learning experience. I learned to narrow down my focus and hit at the heart of what I am doing. I needed the practice. Listening to others pitch their companies gave me lots of examples and helped me to understand how to be more clear and concise.

In reflecting on previous attempts to explain an idea or a proposal through the years, I realized I failed to be clear and concise. I needed a 1 to 2 minute pitch even when I was working at an established company. If I had a 1 to 2 minute pitch then presented the details, I would have been more successful in selling my proposals. Looking back, I’ve created many Powerpoint presentations to explain projects but I bet I just bored the heck out of my audience because I didn’t have my pitch refined and in place.

That conversation about my blog was a good kick in the butt experience for me and joining the small business networking group was just the place to learn what I needed to learn.

So why I am I blogging about managing people? I blog because I want to share what I’ve learned about managing people and the most important skill a manager cultivates, at least in my opinion, is self-awareness.

Communicating more clearly and concisely about my work is something to always be aware of and a skill I need to constantly cultivate. Communication begins with me.

But We’ve Always Done it This Way

But We’ve Always Done it This Way

“But we’ve always done it this way,” he told me as I asked why we needed to continue to track metrics I didn’t think anyone was using. So I asked him, “How are these metrics being used and by whom?” He answered, “Well, I like to track all of these in case someone wants to start using them.”

I then went to several directors to ask them how much time it was taking them to collect these monthly metrics. One said it took time but was no big deal. Another one told me with a smile, “I don’t send them in anymore. I stopped two months ago. No one noticed.” I laughed.

Then I figured out how much time people were wasting on something that wasn’t even being used by anyone for anything. Why? I hate waste. I hate collecting metrics just to collect them. I dislike process just for process sake especially if it takes time that can better be spent elsewhere.

It’s always a good idea to review current processes to understand if they are still effective and supporting the business as expected. However, if you discover people are spending time on information gathering or processes that are ineffective or not being used, then either streamline them or eliminate them.

Some will argue that the process has been in place for so long because it really did solve a problem at one point so it shouldn’t change. These are the people who will find change uncomfortable. A guest blogger, Tarang, wrote about change management. You might be interested in his observations.

People find comfort in processes that have been in place for a long time because they are familiar. Safe. However just consider how much better that time could be spent if those processes are no longer used. Eliminating time wasting processes creates space for new opportunities and new ways of doing things.

After we evaluated and identified which metrics would help us make business decisions, we were able to streamline information in the report. This saved time for those that were collecting the data leaving them more time to focus on releasing the product. They also didn’t feel they were gathering metrics that no one would use.

It’s a good practice to review metrics and processes and fine tune to make sure they are still relevant, meaningful, and helpful.