Tag: professional development

10 Behaviors to Make Your Team Great

Is your team greater than the sum of its parts?

Image for post
Photo by Michael Ankes on Unsplash

My team was in a bit of a rut. There was no trust and poor communication. People weren’t collaborating, and there was no transparency into anyone’s days. Updates in our daily standup meetings were vague and non-committal. Morale was low. Things just weren’t getting done.

I knew it wasn’t a people problem. I’d been with most of the team for years, and everybody was smart and talented. No — this was definitely a behaviors problem.

But, while I could feel the problems, I didn’t know how to articulate them. Before I could address the issues, I needed a better understanding of what they were, and I needed to establish a vocabulary with the team to facilitate a discussion. Only then, with awareness and buy-in, could we begin to implement change to improve our effectiveness.

Good Behaviors, Bad Behaviors

I was discussing the team’s underperformance and collaboration problems with a colleague, and they joking-not-jokingly proposed doing a Five Dysfunctions of a Team exercise. (Disclosure: as an Amazon Associate I earn from qualifying purchases.)

Image for post
The Five Dysfunctions of a Team: A Leadership Fable

It had been a while since the five dysfunctions had been front of mind, and I had to look them up for a refresher. “Let’s see what we’ve got here,” I thought as I clicked through some search results.

  1. Absence of trust — check.
  2. Fear of conflict — yup.
  3. Lack of commitment — oh yea.
  4. Avoidance of accountability — definitely.
  5. Inattention to results — mhmm.

Wow. We had ’em all. People on the team didn’t trust each other to complete assignments. Rather than confront the lack of trust, they preferred to work alone on whatever they felt was most important. Updates in standups would be, “I worked on some things and will figure out what’s next,” and people would leave for a coffee and disappear for the rest of the afternoon. Meanwhile, user stories would drag on for days and weeks with no sense of urgency. Yikes!

The five dysfunctions also reminded me of Project Aristotle. This Google Research project attempts to answer the question, “What makes a team great?” One of their key findings was that effectiveness depended more on how the team worked together than who was on the team. In other words, team dynamics and behaviors matter more than people and individual performance.

…what really mattered was less about who is on the team, and more about how the team worked together

Google’s “five effectiveness pillars” go with the five dysfunctions like peanut butter goes with jelly, combining to create a gooey smattering of team efficiency — and they gave me exactly what I was missing most: a vocabulary for talking about the areas we needed to improve and ways to communicate the importance & impact.

The Actions in Action

Image for post
Photo by Trym Nilsen on Unsplash

I had the concepts. Now I needed to deliver the message. I decided to put together two hypothetical situations based on our very real problems to illustrate the impact of these behavioral patterns & anti-patterns.

Example One. In standup, a dev says, “I’m going to work on implementing the Thingamabob. I’m going to try to complete tasks A, B, & C today, then we can test and close it out tomorrow.” In the afternoon, they say, “Something came up and I need to leave for a few hours, but I’ll be back to finish up. I completed task A and am almost done with B.” They come back later when everyone else is offline, complete task B, and leave a note before signing off: “Completing task B took longer than expected, but I got it done. I wasn’t able to get to task C. I’ll pick it up first thing in the morning.”

Example Two. In standup, a dev says, “Not sure what I’m doing today. I might start working on implementing the Thingamabob.” They start working on the story to implement the Thingamabob and complete task A plus part of task B. They need to leave for a few hours, but they don’t say anything. They come back later when everyone else is offline and complete task B.

In both examples, the person might’ve been equally productive, written brilliant code, and completed the same tasks. In both cases, the person had to leave for several hours, and in both cases they didn’t complete the (stated or unstated) goal of finishing task C.

However, the first example demonstrates all of Google’s dynamics of great teams.

  • Psychological safety. The dev wasn’t afraid to share status or go away because of other responsibilities; they felt safe to let the team know they didn’t complete their stated goal.
  • Dependability: The developer made commitments in standup and was transparent about progress and effort.
  • Structure and clarity: They communicated status so the team had awareness, which allows the team to adjust its actions and priorities. (For example, this could allow someone else to jump in on completing task B while the developer was away, and upon returning they could complete task C versus only completing task B.)
  • Meaning: The developer appreciates having a job that allows them the flexibility to take care of other responsibilities during the day.
  • Impact: Ensuring progress and helping the team achieve its goals feels good.

Conversely, the second example exhibits symptoms of all five dysfunctions.

  • Absence of trust: Low visibility and poor communication lead the team to wonder what the developer is working on.
  • Fear of conflict: Sporadic availability makes it hard to collaborate; team members become exasperated and prefer to work alone.
  • Lack of commitment: The developer was non-committal in standup, and the team has no expectations or ability to coordinate.
  • Avoidance of accountability: No commitments and poor visibility & availability; the dev does nothing to demonstrate their effort.
  • Inattention to results: Individual behavior prevents the team from achieving its goals.

All this is to say that, in order to be an effective team, individuals must focus on their behavior and interactions with teammates more than just being productive themselves.

Staging the Intervention

Image for post
Photo by Todd Quackenbush on Unsplash

Okay, I had my ideas to share, and I had my plan of how I wanted to roll my message out to the team — it was time to put the wheels into motion.

The first thing I did was to send an email using the examples above. My messaging (paraphrasing) was, “Hey, team — I’ve been thinking that we haven’t been as productive lately as we’ve been in the past. I think we’re exhibiting some of the Five Dysfunctions of a Team, and we’ve lost some of Google’s pillars of effectiveness that we had previously. Consider these examples.” I also shared my analysis about how the examples were illustrative of the five dysfunctions and effectiveness pillars.

I didn’t really get feedback on the email, but there was a mention here & there in standups and retrospectives. I feel like the email did a fine job of planting the seed and helping to establish a vocabulary for the conversation. Mission accomplished there, I’d say.

Step two was to solicit feedback in one-on-ones. I’d ask people what they thought about the email and how they felt about the team in that context. These conversations were helpful because it confirmed my feelings and demonstrated that others were experiencing similar frustrations. This also helped to establish that we were all on the same page and had similar perceptions of our team strengths and weaknesses.

Finally, I decided to bring it up in the team’s sprint retrospective. I was blunt with them. I said, “I don’t think the team is doing enough to demonstrate commitment & accountability.” It took some courage, but I had to trust the team and not fear conflict — to practice what I was about to preach. The groundwork I’d laid proved valuable. People referenced the email I’d sent, and we’d all had miniature versions of the discussion in one-on-ones. It was a really productive conversation and a catalyst for positive change.

Image for post
Photo by Danielle MacInnes on Unsplash

Things didn’t fix themselves overnight, but we began trending positively in just a week or two. People started giving updates like, “My goal for today is …” and leaving messages at the end of the day to highlight what they did and didn’t accomplish.

If your team can buy-in on the importance of these dynamics and be self-reflective & honest, it can lead to some pretty incredible growth — even on a team that’s already high-performing and seemingly happy. Awareness of these dynamics can turn things around on an underperforming team or protect a happy, productive team from growing pains and evolution.

My team isn’t perfect, but we’re getting better every day. The next step was to continue the momentum. We planned a recurring team meeting to focus on these behaviors and team growth to increase introspection and awareness, but the best way to keep improving is by walking the walk. Psychological safety, trust, commitment, accountability, and no fear of conflict allow us to continue having productive conversations and ensure that we stay on track to accomplish great things together.

Resources:

Originally published at The Innovation on November 20, 2020.

Advertisement

Transitioning from Developer to Manager

Image for post
Photo by Fabrizio Verrecchia on Unsplash

It’s not uncommon for successful software developers to find themselves in leadership positions. There are many possible leadership trajectories, one of which is management. Moving into management was scary for me, and over the years I’ve talked to a number of people at that point in their careers experiencing a similar dilemma. This is the story of my experience, why I made the decision I did, what I’ve learned along the way, and how it’s turned out.

The pre-management era

Let’s start with a little about my background, eh? I started my career as a junior developer and worked my way into a senior role, eventually becoming an architect. As an architect, I served as the technical lead for my team and worked closely with managers to make various leadership decisions. I wore many hats in order to best address whatever I felt my team needed most at the time.

After nearly 10 years with my first company, I left to join a former co-worker at a startup. At the time, this new company was small enough that we didn’t have much of an organizational hierarchy. We were a group of senior developers that all had decision-making authority with freedom to work on what we felt was most important. We still collaborated, of course, but we weren’t all chipping away at a common product backlog.

The loose structure worked great for us as a small team, but it doesn’t scale. As we added more people to the team and new products to our catalog, we needed more structure. We divided into product-specific teams with narrower focus and dedicated backlogs. That was our no/low-management tipping point, and that’s where my journey into management begins.

My boss was suffering the consequences of our very flat organization, and they needed people willing to take on some of these managerial responsibilities. I felt like I was being forced to commit: did I want to be a manager or not? I wasn’t given an ultimatum; in fact, my boss was very clear that there was no wrong choice, and my career would continue to grow regardless. That was comforting, but I still had the decision to make.

The management path was scary for a variety of reasons. I had a proven track record as a developer. I was good at coding and troubleshooting. I knew how to solve software problems. Managers take on an entirely different set of problems that require a different skills — skills I wasn’t sure I’d have. Managing a team when things are going well didn’t seem so bad, but it’s the whole “dealing with people” thing that had me worried. Did I really want to give up coding — the thing I enjoyed and had built a successful career doing — to be a manager and have to deal with people?

Making the decision

I ended up lingering at this juncture for a while. Depending on the day, I might’ve leaned one way or the other, but for the most part I remained undecided and non-committal. In my free moments, I’d research what made a good manager and read stories like this one to understand other people’s experiences. There were a few nuggets of wisdom that helped me make my choice.

Skills can be learned. It feels obvious to say, but hearing this was reassuring because I always considered “learning new skills” to be one of my strengths. It gave me confidence to know that I could supplement applicable existing skills with new, learned skills. For example, I know how to troubleshoot an application by stepping through code until I find a problem, then come up with a solution and implement it to fix the issue. The same critical thinking can be used to identify problems with a team, but I may need to do research on agile processes or collaboration techniques to come up with the solution.

You can nerd out on management. As a developer, there are always new things to learn and play with: languages and language features, tools, technologies, and techniques. I remember learning about something like Microsoft Azure for the first time and being so excited to have a reason to use it. The same kinds of continuous innovation exist for managers, too, but you need some awareness of manager & team problems in order for the solutions to make sense — just like you need context for those new things in software development. How can you automate team processes to reduce toil? What things cause the most friction or prevent work from getting done? How can you make 1:1s more effective? How can you maximize the team’s impact on company goals? How can you improve individual accountability? These are all super valuable areas to focus on, and they’re ripe for fresh ideas and innovation.

There is no “point of no return.” I was worried I’d go from awesome dev to mediocre manager, be unhappy, lose my edge, and feel trapped. It was reassuring to hear that I could go back and that my development skills wouldn’t disappear after being less active for a bit. I’m less involved in daily development tasks now and there are a lot of pull requests doing thing that I don’t understand, but when I do get back into the code, it all comes back.

As you may have guessed, I decided that moving into a manager role was the right move for me, and I’ve been at it for a few years now. It hasn’t always been fun or easy, but the more I do it, the more proficient I become. This has a cyclical effect, too, because increased proficiency leads to more engagement which brings more enjoyment and satisfaction.

Learning to manage

The most difficult thing about becoming a manager for me was the self doubt. (See imposter syndrome.) I felt like I was less valuable to the team “managing” than if I was a developer focused on getting things done. I wasn’t sure if I was spending my time on the right things, and the things I was spending my time on were different than that of my peers/other managers. I was failing to adequately help team members that weren’t meeting expectations. I was doing the best I could, and my boss was supporting and encouraging me — but I didn’t feel like I was doing a good job. It was tough.

Looking back, I think there were two key mistakes I made as a new manager. The first was not being direct with people. I was trying to focus on positive behaviors and encouragement and not being explicit about areas that needed improvement. The second mistake was that I didn’t think about the strengths and weaknesses of individuals on the team and strategize how to use them most effectively. (More on that, here!) You can imagine how these two mistakes can create problems: praise for strengths versus less feedback & higher expectations for weaknesses. It’s no surprise that situations didn’t improve!

The single most important advice I have for new managers is to lead with empathy. Get to know your team, and treat them like people. Give them positive and negative feedback. You’d want your boss to tell you if did something wrong, right? But, it would start to feel bad if they only talked to you about the things you did poorly, too. Learn details about their lives outside of work. It would get annoying if you had to re-explain every week why you had to be late to the same meeting for same reason. The better you can understand your team — professionally and personally — the more effectively you can manage.

The best way to get to know your team is through one-on-ones. One-on-ones are a pretty common “most important thing” for new managers, but the thing it took me a while to learn was how to prepare for one-on-ones. This is very hand-in-hand with leading with empathy. Being prepared for these intimate meetings is the best way to demonstrate that you care. Come up with questions and topics that are specific to the person you’re talking to. What do they like or not like about their job? What are their goals, and are there things you can do to help ensure they’re progressing toward them? What are things they did well or poorly? What do they think they did well or poorly? It’s also a chance to solicit feedback from them about you. Be sure to take notes! They’ll help ensure you don’t miss important follow-ups and make preparing for the next meeting easier.

The next steps

Managing with empathy and preparing for & conducting one-on-ones are things you can implement immediately regardless of experience. The next steps take some time and depend on your team. The most important things will be to establish behaviors that will maximize effectiveness and define a clear vision and purpose. These are no easy feats, though. They require thoughtfulness, focus, strategy, and persistence & dedication. You must monitor progress and be wary of regression, and advocate for the right amount of change to keep things trending positively. And, you need to do all this in addition to whatever your team needs to keep things going operationally!

This is a good summary of what my day-to-day looks like now. I’ve got meetings and operational concerns, and then extra time goes into reflection and solutioning for these bigger, longer-term items. There are still ups & downs; still days where I feel like I’m doing a bad job; and still days where I wish I could just write some code. It’s been a rewarding experience, though. It’s been amazing to watch the team adapt & succeed and to help people grow. I love when we can take on an ambitious goal and achieve it.

Making the transition to manager was a scary decision. I had to learn new skills to solve new types of problems, and I had to battle through some self-doubt. I don’t regret my choice, though. I’m not perfect, I make mistakes & bad decisions, and I’m still learning as I go. But, I love my teams, and I love the problem space that I get to live in.

Have you made this transition yourself? What things have helped you succeed? Are you faced with the decision now — what worries you? I’d love to hear from you!

Originally published at The Innovation on November 7, 2020.

Why are you doing that?

We’ve all been there before: the boss approaches and asks you to do something that seems useless. You don’t ask questions. You just do it because they’re the boss, and that’s what they asked you to do.

“Why are you doing that?”
“I don’t know.”
“It seems dumb, doesn’t it?”
“Yes.”
“Then why are you doing that?”
“Boss told me to.”

Ugh. Don’t you see? Everybody loses when this happens! You’re doing something you perceive as useless, so you probably feel like you’re time is being wasted. You’re also probably not putting forth your best effort since you’re doing something you think is useless. Plus, you don’t understand the reason you’re doing it, so there’s a good chance you might overlook something that’s relevant to the actual goal. So even if you’re trying your best, you might not be as effective as you could be. Maybe there’s a better way to accomplish the goal than what you’re being asked to do, but how can you know without having any awareness of said goal?

I see this all the time, and it drives me CRAZY. It’s sad, too, because the solution is so simple: ask questions. Don’t do something without understanding why you’re doing it. The worst reason you can have for doing something is because somebody told you to do it. The next worst reason is that it’s what you’ve always done. If you’ve been given an assignment, and you don’t understand why you’re doing it, don’t just do it: ask some damn questions! You’re smart. You have ideas. If you understand the problem you might be able to come up with some smart ideas about how to solve it. (And if you can’t, at least you’ll understand why you’re doing that dumb thing you’re doing.)

You might be able to do an okay job by just doing what you’re asked to do without knowing why you’re doing it. You’ll probably do a better job if you know what’s trying to be accomplished, but you’ll do your best work if you can somehow find a way actually care about the problem. Mindlessly doing what your told is a fantastic way to be mediocre and not have a satisfying career. Being engaged plays an important role in both performance and satisfaction. You must understand a problem in order to care about it, and only when you care will you become truly engaged–unlocking your full potential, producing your best work, and feeling maximum satisfaction for what you’ve accomplished.

11 Simple Concepts to Become a Better Leader

Article: 11 Simple Concepts to Become a Better Leader

This is a typical be-a-good-person-and-people-will-like-you article, but it’s good to remind ourselves of that from time to time. The concepts presented in the article that I feel are most important are transparency, adaptability, and gratefulness.

Transparency is a great leadership quality because it earns trust over time. I hate playing games. It doesn’t get anybody anywhere. If you told me you were going to start working on a project but got distracted, don’t tell me that it’s moving along just fine. Tell me you got distracted and haven’t started, but also tell me when you’ll be starting it and what will be the impact on the project timeline. Being transparent also drives customer satisfaction because it helps set and adjust expectations.

I presume the importance of adaptability transcends industry–hence its inclusion in the list–but it’s incredibly important for software development. In my experience, it’s pretty rare to have a project that goes 100% as planned. Next to never. And I’m talking about “next” being on the other side of never, not the side where it might actually happen. Understanding when to deviate from the plan is key. It might be to overcome a challenge: “We thought we could do X, but that’s not going to work. Let’s do Y instead.” It’s not always a problem that makes adapting advisable, though; it could be an unforeseen improvement: “We planned on doing X, but it makes more sense for the users if we do Y.”

And, finally, gratefulness. My least favorite type of co-worker is the ungrateful leech. You never hear from them until they need something. Then, you go out of your way to help them out–because you’re awesome and that’s how you roll–and you’re lucky to get an email that says, “Thanks.” When those guys come around looking for help, I don’t like to give it to them. On the other hand, you’ve got people who genuinely appreciate what you’ve done. They offer to buy you lunch or a drink. Gratefulness goes a long way, even if it’s just saying, “Seriously–thanks. You really helped.” When those guys need help, I’m happy to drop what I’m doing to give it to them. It’s not because I hope to get free stuff, it’s because I know my effort will be appreciated. As a leader, you’re playing the role of the guy who needs stuff in these scenarios. Do you want to be the guy that people do things for because they have to or because they want to?

Disagreement as an Expectations Management Technique

Link: Disagreement as an Expectations Management Technique

I’ve been to mechanics. I’ve pretended to know what’s going on. I’ve been blind-sided by an actual bill that’s several times larger than what I had expected.

This article makes several great points about expectations management. Transparency and honesty improve customer satisfaction over time, even if they bring bad news. Disagreement is a part of that. When a customer comes to you with an expectation that you disagree with, you need to set them straight. If I’m the customer, I’d rather be informed and educated about the incorrectness of my assumptions than be upset and disappointed after the work is done.

Finding Time to Innovate

Innovation is the backbone of any software development effort. If you aren’t doing something new, what’s the point? Without new ideas, you’ll never be first, you’ll never have something that your competitors don’t, and you will never be the best.

I think most people would agree with these statements when talking about a software company or product, but I’m actually talking about developers. You–the developer–need to constantly explore new ideas and learn new skills. Doing things you’ve always done the way you’ve always done them will likely never result in anything more than marginally better than what you have now. (Hey, more = better, right?) In other words, you will need to do new things in new ways in order to produce something significantly better than what you have now.

This is where things get a little less straightforward. How do you learn to do things you haven’t done in ways you haven’t done them before? In my opinion, it’s all about exploration and experimentation. When I read an article about a new tool or language feature, I’ll spend some time playing around with it. I don’t necessarily have a use in mind; I just want to see what it’s about. The result over time is that I have a whole host of things I’ve messed around with that are implementation-detail candidates on future projects. Additionally, when discussing new projects, I can say things like, “This is useful, but it would be really cool if we added X. Here’s how we can do that.”

We can all agree that innovation is essential, and it’s important for developers to spend time learning and exploring to help with the innovating. There are only so many hours in the day, though, and you’ve probably got other, more important things to work on. You’d love to spend time trying new things, but your boss isn’t going let you have free time to do that. After all, there’s money to be made! So what can you do?

I work for a somewhat old-school software company. The senior management overseeing development isn’t likely to institute 20% time any time soon. They aren’t going to designate a percentage of hours as play time, but that doesn’t mean that creativity is forbidden or frowned upon. It just means you have to find the time yourself. I’d venture to say that most software developers are salaried employees obligated to 40 hours per week but expected to work more. What if you spend just one hour each day learning something new? You’ll probably still be giving 40+ hours of effort to the “actual work,” but you’ll also be learning new things that interest you. Fast math shows us that 5 hours represents 11% of a 45-hour week so, by taking 1 hour each day you effectively create “10% time” for yourself.  If one hour is too much time for you, take 30 minutes, or do it every other day. Take the time and stick it on the end of your lunch hour if you need a bigger block.

By allocating “you time” and spending it, you’re going to grow professionally, and that benefits both you and your employer. You’ll be better equipped to tackle complex problems in the future, and you’ll have fresh ideas for how to solve old problems. You’ll also have increased job satisfaction because you get to work on things that interest you in addition to your regular assignments. I believe it’s a true win-win scenario. So stop worrying about the hours you’re “given,” and go learn something!

Co-Branded Employees

Last week, the Wall Street Journal posted an article titled “Your Employee Is an Online Celebrity. Now What Do You Do?” The article is about the pros and cons of “co-branded employees:” employees that actively build and maintain their own personal brand outside of work. The goal of the article is to shed light on this type of employee and present some of the potential advantages and disadvantages.

The article begins with the following statement: “meet your newest management headache: the co-branded employee.”

That’s a pretty harsh introduction, but the rest of the article isn’t quite so negative. It’s actually part cautionary and part risk assessment. Several valid concerns are brought forth, such as How much time during the workday should be allocated or permitted? andWho owns the content? There’s also a “balance sheet” that compares several advantages and disadvantages.

Advantages:

  • Prestige – The company can claim the top-ranked employee as their own
  • Leads – By engaging publicly, the employee is potentially attracting new customers
  • Free media – A large following can equate to free or inexpensive publicity for the company
  • Recruitment – The employee will attract other, aspiring minds

Disadvantages:

  • Prima donnas – Popularity can lead to inflated egos and expectations
  • Distraction – The employee may dedicate a wrongly proportional amount of time to their extra-curricular activity
  • Leaks – Internal details may be deliberately or accidentally become “less internal”
  • Resentment – The employee’s popularity or reputation could negatively affect the team

These potential risks and rewards are part of a short list that could clearly be much longer. I started blogging to track things that I’ve learned and figured out, and it’s evolved into a hobby that doubles as a profession-growth mechanism.

Does it take time out of my day? Sure. A lot of things that I learn and write about are directly related to what I’m doing at work. There’s probably an argument to be made that tasks take me longer to complete because of my blogging. After all, I’d be done sooner if I didn’t have to scrub out customer-related info and write several paragraphs about why I was doing something and how I ultimately accomplished it.

The flip-side to that is that the quality of my solutions is improved by the additional diligence that comes along with my desire to write. I don’t stop when it works. I go deeper; I want to understand why it works, what’s necessary, and what’s not. Then, I take all of that information, condense and simplify it into a blog post. That post becomes my own, searchable repository of lessons learned. If somebody on my team is faced with a similar task, I can send ’em a link. They get an abbreviated version of the journey with a (hopefully) clean, concise  solution.

I can only speak in terms of my own experience, but I’d certainly argue that activities like this are a win-win. My online presence, and the desire to grow it, result in an expansion of my horizons. I get personal satisfaction from learning and exploring new topics. The knowledge gained through these exercises allows me to think outside the box when solutions are needed. I’m more well-rounded because of it, and I’m more capable of supporting and providing guidance to my team on solutions old and new, alike.

The “Art” of Communication

I’m a drawer. (One who draws, not to be confused with one in a dresser.) Three sentences into any explanation, I start looking around for a whiteboard. I don’t know what I want or am going to draw, I just know that I need to do it.

Sure, I like changing databases into monsters, but that’s not the only reason I draw pictures to supplement many of my discussions. This article at Inc does a good job of identifying several advantages of visual explanations. Here’s the summarized list:

  1. Out of sight is literally out of mind
  2. Visuals allow the brain to take shortcuts
  3. Brains like the familiar
  4. Making hard stuff friendly improves communications

The last point is really the most important for me. If I’m describing a complex system to a peer, it takes a lot of words. It’s really easy to lose track of the pieces. Creating a quick doodle does a better job, and it lets the audience revisit the parts they may not understand by continuously examining the picture. It’s also essential as you communicate ideas to folks at different stages of the Dreyfus model–both higher and lower. A customer might not understand what it means to serialize an object to XML and send it via a socket connection, but they’ll understand what a box labeled “data” with an arrow means.

I like the first point that was made, too: out of sight is literally out of mind. If you diagram the entire system before talking about a change, it’s less likely that you’ll forget about a piece of it when considering the implications of the change. On a note unrelated to visuals, this is also important to keep in mind in any meeting that ends with actionable items. Make sure to document who’s responsible to do what. The verbal agreement is “out of sight” and, therefore, at risk to become “out of mind.”

Have you ever sat through a PowerPoint presentation where each slide has 100 words? It’s not good. You spend more time reading words than listening to the speaker. Even worse is when the speaker goes faster than you can read. You get 3/4 of the way through a slide without hearing a word from the speaker only to be cutoff as they move to the next slide. I really like the example of Jobs as a compelling reason to use visuals as shortcuts. If you show me a slide with a solid block of text, I’m far less likely to retain your message than if you were to show me a slide with a single word, phrase, or image. Keep the message in your slides clear and direct, and speak about the rest.

Listen Slowly, Interview Better

 

Inc.com has an article by Jeff Haden from earlier this week titled “Best Interview Technique You Never Use” that I thought offered some good advice. The article suggests that you’ll get more information and insight by simply pausing for a 5-count before moving on to the next question. Just as it is natural for you, the interviewer, to want to ask another question to kill the silence, the candidate is likely to do the same by elaborating on their response.

I know I’m definitely guilty of doing the opposite, firing question after question at a candidate immediately once I think they’ve finished their response. My rapid-fire technique results in very fast interviews that only scratch the surface. I’m relatively new to interviewing at this stage in my career, and I don’t think I’ve become particularly adept at it yet. Perhaps part of the problem is that I haven’t been listening slowly enough.

This is definitely a tip that I’m going to keep in mind as I work to become a more effective interviewer.

 

Software Developer Advice: Be Reputable!

If you want to have a successful career in software development, I have one very good piece of advice to offer: put your reputation above all else. I imagine this advice translates to other industries, but it’s certainly true in the world of software development. Here are some tips that you can use to help build and maintain a strong reputation as a developer.

Think like a user

Thinking like a user is a wonderful ability for a developer. When you add a piece of functionality, think to yourself, “How would I like this as a user?” Would you want to type in a file path? Probably not. You’d rather have some sort of browse capability that let’s you click through directories to find a file. Would you like browsing to an install directory, opening a config file, and editing XML to change a setting? Doubtful. You want to click a button or pick a menu option in the application to change settings.

I like to say that I “create software that works like software should,” and it’s all about thinking like a user. Users don’t want complicated, unintuitive solutions. They want something that is easy to use, does what it’s supposed to, and looks good. Think like a user, and create great products. Nothing will produce a better reputation than consistently producing great products!

Have higher standards than everybody else

Let’s say you–a customer–have low standards, and I–a developer–have “normal” standards. I give you an application that meets my normal standards. It has some minor bugs, but it’s generally functional. Since you have low standards, you’re probably happy with it, and we have good product satisfaction.

Now let’s say you have higher standards than me. I give you my same, normal-quality application. The previous flaws are now less acceptable, and satisfaction decreases. We get into a situation where satisfaction is mediocre. Easy-to-please customers like it, hard-to-please customers don’t.

If you hold yourself to a higher standard than everybody else, though, it’s likely that you’ll delight users more often than not. When a solution isn’t up to snuff, you need the courage and discipline to put the brakes on. Make sure it meets your standards before handing it off to others, and that brings me to my next point…

Ask for more time

Never, NEVER say development is done before you believe it is. I’ve had discussions with co-workers over the years that go like this: “Managers only care about closing projects. They don’t care about quality or doing it right.” It’s definitely true that managers care about closing projects, and rightfully so–you should, too! I don’t believe they want it happen at the expense of quality, though. If they do, they’re a bad manager, and you need to figure out how to make sure their bad managing doesn’t bring you down. I’d venture to say that 99.99% of managers and customers in the world will prefer a complete/good solution 2 weeks late over a partial/bad one delivered on time. So, when you need more time, you should ask for it.

There are some tricks to asking for more time, though. First and foremost, try to ask before you’ve actually run out of time. Everybody will be annoyed with you if they’re expecting a product on Monday and you tell them on Friday that it won’t be done. On the other hand, if you come to them two weeks before the deadline to request an extra week, it will likely be more well-received. And so comes the next trick: know how much time you need. You won’t be doing yourself favors by extending the deadline, and then extending it again, and then again. When you know you’re not going to finish on time, evaluate the work that needs to be done and estimate how much effort will be required. This will help in your explanation of why you need more time while simultaneously helping to ensure you ask for a sufficient amount of time.

Have integrity

I’m telling you that your reputation is the most important thing you have, but you should never try to protect or improve it by sacrificing honesty or integrity. If you make a mistake, own up to it, and grow from it. In fact, the bigger the mistake, the more important this becomes. Let’s say you introduce a bug that cripples your customers.  Clearly, it would be better to take action, letting everybody know about the critical issue and working to resolve it, rather than letting it be discovered on its own and inevitably traced back to you! Acknowledge that you made a mistake, and do whatever you can to help make it right.

Being open and honest will earn you the respect of your peers, your managers, and your customers. Treat others as you wish to be treated. When I’m asked a question, I answer to the best of my ability, providing accurate information–good or bad–along with relevant supporting details. I respond that way because that’s the type of response I hope to get when I ask a question. If you don’t provide accurate information, you’ll soon find that people don’t care what you have to say.

%d bloggers like this: