Newer posts are loading.
You are at the newest post.
Click here to check if anything new just came in.

May 01 2012

Want to get ahead in DevOps? Expand your expertise and emotional intelligence

Kate Matsudaira (@katemats), VP of engineering at Decide, will be hosting a session, "Leveling up — Taking your operations and engineering role to the next level," at Velocity 2012 in June. In the following interview, Matsudaira addresses a few of the issues she will explore in her session, including the changing roles and required skill sets for today's developers and engineers.

How are operations and engineering jobs changing?

Kate Matsudaira: Technology has been advancing rapidly — it wasn't more than a decade ago when most software involved shrink-wrapped boxes. Things have evolved, though, and with open source, web, and mobile, the landscape has changed. All of the advances in languages, tools, and computing have created a plethora of options to build and create solutions and products.

In the past, engineering roles were specific, and people tended to specialize in one platform or technology. However, as systems have become more complex, and more organizations adopt virtualization, cloud computing, and software as a service, the line between software engineer, operator, and system administrator has become more blurry. It is no longer sufficient to be an expert in one area. People are expected to continuously grow by keeping up with new technology and offering ideas and leadership outside their own purview. As engineering organizations build systems using more and more third-party frameworks, libraries, and services, it's increasingly necessary for engineers to evaluate technologies not solely on their own merits, but also as they fit into the existing enterprise ecosystem.

What are the most important soft skills developers and engineers need to cultivate?

Kate Matsudaira: When it comes to our careers as engineers, learning new technologies and solving problems has never been much of a challenge. And I would argue that most of us actually really enjoy it — and that is part of why we are good engineers. So, certainly understanding the tools and possessing the knowledge to do your work is important.

Putting knowledge and learning aside, there are many soft skill areas that can impact an individual's success and prevent them from realizing their potential. For example, things like communication, influence, attitude, time management, etc., are just the start of a long list of areas to improve.

The specifics may be different for each individual. However, almost everyone — myself included — could stand to improve their communication skills. Whether it is managing up to your boss, getting buy-in from stakeholders, or helping resolve a technical debate with your team members, learning to communicate clearly and effectively can be a challenge for some people.

Communication is the cornerstone of leadership. Learning how to bridge business and technology can help technologists take their careers to the next level. Organizations value people who can clearly explain the trade-offs or return on investment of a feature, or the person who can help their coworkers understand the internal workings of systems. Becoming a better communicator is good career advice for pretty much anyone.

Velocity 2012: Web Operations & Performance — The smartest minds in web operations and performance are coming together for the Velocity Conference, being held June 25-27 in Santa Clara, Calif.

Save 20% on registration with the code RADAR20

Your Velocity 2012 session description mentions "emotional intelligence." Why is that important?

Kate Matsudaira: Improving my "emotional intelligence" is something I have had to work on a lot personally to grow in my career. Emotional intelligence is the idea that there is a set of qualities that helps one excel to a higher level than another person with similar cognitive skills (for more on the topic, there is a great article here on what makes a leader).

The definition of emotional intelligence includes a cocktail of self-awareness, self-regulation, empathy, motivation, and social skill — and who wouldn't want to be better in those areas? But for me, as an introvert who tends to like the company of my computer better than most people, things like social skills and self-awareness weren't exactly my strengths.

Since emotional intelligence can be learned, one can find ways to improve and be better in these areas. The first step to making progress is to really understand where you need to improve, which can be a challenge if you are lacking in self-awareness. However, making improvements in these areas can help you become more successful without becoming something that you are not (i.e. introverts can realize their potential without becoming extroverts).

What are specific strategies geeks can use to improve communications with non-geeks?

Kate Matsudaira: There are a lot of strategies I have come up with that work well. I tend to think about social situations like pattern recognition, and come up with frameworks and templates to help me muddle through — and sometimes flourish — in situations that are out of my comfort zone.

When it comes to communicating with non-geeky types, here is a good outline to get you started:

  1. Look at the situation from their point of view. What knowledge do they have? What are the goals or outcomes that matter to them? What are they trying to achieve, and how does your involvement help/hinder their path? Empathy will help you learn to appreciate their work and help them relate to you as a teammate and colleague.
  2. Get on the same page. Listen to their point of view and make sure you understand it. A great way to do this is to repeat back what they tell you (and not in a patronizing way, but in a constructive way to ensure you heard and understood correctly). What are their objectives? What are their concerns? How do they want you to help?
  3. Make them feel smart. Non-technical or non-geeky people often complain that they can't understand developers or engineers, and some technologists like it that way. And while this may make the technologist feel smart, it also creates a barrier. The greatest technologists know how to communicate so that everyone understands. Take the time to explain technical issues at a level they can understand in the context that matters to them (such as business metrics, customer impact, or revenue potential).
  4. Reassure them. Since they may not know the technology, what they want to know is that you (and your team) have things under control. They want to know the end result and timeline, and most of the time they don't want to know about the "how." Keep this in mind and help them achieve peace of mind knowing that you are on top of handling the task at hand.

Of course, each situation is different, but really looking at the situation from the other person's point of view and helping them is a great way to build relationships and improve communication.

This interview was edited and condensed.


October 10 2011

Moneyball for software engineering

While sports isn't always a popular topic in software engineering circles, if you find yourself sitting in a theater watching "Moneyball," you might wonder if the story's focus on statistics and data can be applied to the technical domain. I think it can, and gradually, a growing number of software companies are starting to use Moneyball-type techniques to build better teams. Here, I'd like to provide you a brief introduction to some of these ideas and how they might be applied.

The basic idea of the Moneyball approach is that organizations can use "objective" statistical analysis to be smarter and build more competitive teams, which means:

  • Studying player skills and contributions much more carefully and gathering statistics on many more elements of what players do to categorize their skills.
  • Analyzing team results and player statistics to discover patterns and better determine what skills and strategies translate to winning.
  • Identifying undervalued assets, namely those players, skills, and strategies that are overlooked but which contribute heavily to winning.
  • Creating strategies to obtain undervalued assets and build consistent, winning teams.

While smaller-market baseball teams such as the Oakland A's were the original innovators of Moneyball, these techniques have now spread to all teams. The "old-school" way of identifying talent and strategies based on experience and subjective opinion has given way to a "new school" that relies on statistical analysis of situations, contributions, and results. Many sports organizations now employ statisticians with wide-ranging backgrounds to help evaluate players and prospects, and even to analyze in-game coaching strategies. Paul DePodesta, who was featured in both the book and the film, majored in economics at Harvard.

In software engineering, most of us work in teams. But few of us utilize metrics to identify strengths and weaknesses, set and track goals, or evaluate strategies. Like baseball teams of the past, our strategies for hiring, team building, project management, performance evaluation, and coaching are mostly based on experience. For those willing to take the time to make a more thorough analysis through metrics, there is an opportunity to make software teams better — sometimes significantly better.

Measure skills and contributions

It starts with figuring out ways to measure the variety of skills and contributions that individuals make as part of software teams. Consider how many types of metrics could be gathered and prove useful for engineering teams. For example, you could measure:

  • Productivity by looking at the number of tasks completed or the total complexity rating for all completed tasks.
  • Precision by tracking the number of production bugs and related customer support issues.
  • Utility by keeping track of how many areas someone works on or covers.
  • Teamwork by tallying how many times someone helps or mentors others, or demonstrates behavior that motivates teammates.
  • Innovation by noting the times when someone invents, innovates, or demonstrates strong initiative to solve an important problem.
  • Intensity by keeping track of relative levels and trends, increases or decreases in productivity, precision, or other metrics.
  • Effort by looking at the number of times someone goes above and beyond what is expected to fix an issue, finish a project, or respond to a request.

These might not match the kinds of metrics you have used or discussed before for software teams. But gathering and analyzing metrics like these for individuals and teams will allow you to begin to characterize their dynamics, strengths and weaknesses.

Web 2.0 Summit, being held October 17-19 in San Francisco, will examine "The Data Frame" — focusing on the impact of data in today's networked economy.

Save $300 on registration with the code RADAR

Measure success

In addition to measuring skills and contributions for software teams, to apply Moneyball strategies, you will need to find a way to measure success. In sports, you have wins and losses, so that's much simpler. In software, there are many ways a software team may be determined to succeed or fail depending on the kinds of software they work on, such as:

  • Looking at the number of users acquired or lost.
  • Calculating the impact of software enhancements that deliver benefit to existing users.
  • Tracking the percentage of trial users who convert to customers.
  • Factoring in the number of support cases resulting from user problems.

From a Moneyball perspective, measuring the relative success of software projects and teams is a key step to an objective analysis of team dynamics and strategies. In the end, you'll want to replicate the patterns of teams with excellent results and avoid the patterns of teams with poor results.

Focus on relative comparisons

One important Moneyball concept is that exact values don't matter, relative comparisons do. For example, if your system of measurement shows that one engineer is 1% more productive than another, what that really tells you is that they are essentially the same in productivity. But if one engineer is 50% or 100% more productive than another, then that shows an important difference between their skills.

You can think of metrics as a system for categorization. Ultimately, you are trying to rate individuals or teams as high, medium, or low in a set of chosen categories based on their measured values (or pick any other relative scale). You want to know whether an engineer has high productivity compared to others or shows a high level of teamwork or effort. This is the information you need at any point in time or over the long term to identify patterns of success and areas for improvement on teams. For example, if you know that your successful teams have more engineers with high levels of innovation, intensity, or effort, or that 80% of the people on a poorly performing team exhibit a low level of teamwork, then those are useful insights.

Knowing that your metrics are for categorization frees you up from needing exact, precise measurements. This means a variety of mechanisms to gather metrics can be used, including personal observation, without as much concern that the metrics are completely accurate. You can assume a certain margin of error (plus or minus 5-10% for example) and still gather meaningful data that can be useful in determining the relative level of people's skills and a team's success.

Identify roles on the team

With metrics like those discussed above, you can begin to understand the dynamics of teams and the contributions of individuals that lead to success. A popular concept in sports that is applicable to software engineering is that of "roles." On sports teams, you have players that fill different roles; for example, in baseball you have roles like designated hitters, pitchers, relievers, and defensive specialists. Each role has specific attributes and can be analyzed by specific statistics.

Roles and the people in those roles are not necessarily static. Some people are truly specialists, happily filling a specific role for a long period of time. Some people fill one role on a team for awhile, then move into a different role. Some people fill multiple roles. The value of identifying and understanding the roles is not to pigeon-hole people, but to analyze the makeup and dynamics of various teams, particularly with an eye toward understanding the mix of roles on successful teams.

By gathering and examining metrics for software engineering teams, you can begin to see the different types of roles that comprise the teams. Using sports parlance, you can imagine that a successful software team might have people filling a variety of roles, such as:

  • Scorers (engineers who have a high level of productivity or innovation).
  • Defenders (engineers who have a high level of precision or utility).
  • Playmakers (engineers who exhibit a high level of teamwork).
  • Motivators (engineers who exhibit a high level of intensity or effort).

One role or skill is not necessarily more valuable than another. Objective analysis of results may, in fact, lead you to conclude that certain roles are underappreciated. Having engineers who are strong in teamwork or effort, for example, may be as crucial to team success as having those who are highly productive. Also, you might come to realize that the perceived value of other roles or skills doesn't match the actual results. For example, you might find that teams filled with predominantly highly productive engineers might not necessarily be more successful (assuming that they lack in other areas, such as precision or utility).

Develop strategies to improve teams

With metrics to help you identify and validate the roles that people play on software teams, and thereby identify the relative strengths and weaknesses of your teams, you can implement strategies to improve those teams. If you identify that successful teams have certain strengths that other teams lack, you can work on strengthening those aspects. If you identify "undervalued assets," meaning skills or roles that weren't fully appreciated, you can bring greater attention to developing or adding those to a team.

There are a variety of techniques you can use to add more of those important skills and undervalued assets to your teams. For example, using Moneyball-like sports parlance, you can:

  • Recruit based on comparable profiles, or "comps" — profile your team, identify the roles you need to fill, and then recruit engineers that exhibit the strengths needed in those roles.
  • Improve your farm system — whether you use interns, contract-to-perm, or you promote from within, gather metrics on the participants and then target them for appropriate roles.
  • Make trades — re-organize teams internally to fill roles and balance strengths.
  • Coach the skills you need — identify those engineers with aptitude to fill specific roles and use metrics to set goals for development.

Blend metrics and experience

One mistaken conclusion that some people might reach in watching the movie "Moneyball" is that statistical analysis has completely supplanted experience and subjective analysis. That is far from the truth. The most effective sports organizations have added advanced statistical analysis as a way to uncover hidden opportunities and challenge assumptions, but they mix that with the personal observations of experienced individuals. Both sides factor into decisions. For example, a sports team is more likely to draft a new player if both the statistical analysis of that player and the in-person observations of experienced scouts identify the player as a good prospect.

In the same way, you can mix metrics-based analysis with experience and best practices in software engineering. Like sports teams, you can use metrics to identify underappreciated skills, identify opportunities for improvement, or challenge assumptions about team strategies and processes by measuring results. But such analysis is also limited and therefore should be balanced by experience and personal observation. By employing metrics in a balanced way, you can also alleviate concerns that people may have about metrics turning into some type of divisive grading system to which everyone is blindly subjected.

In conclusion, we shouldn't ignore the ideas in "Moneyball" because it's "just sports" (and now a Hollywood movie) and we are engineers. There are many smart ideas and a lot of smart people who are pioneering new ways to analyze individuals and teams. The field of software engineering has team-based dynamics similar to sports teams. Using similar techniques, with metrics-based analysis augmenting our experience and best practices, we have the same opportunity to develop new management techniques that can result in stronger teams.

Jonathan Alexander discussed the connection between "Moneyball" and software teams in a recent webcast:

Photo: TechEd 617 by betsyweber, on Flickr


November 21 2007

TERRA 403: The Water Carriers PART THREE

In part three of The Water Carriers, Nina gives Callie a small taste of what it's like to be a water carrier, and the Engineers Without Borders help the village overcome a stumbling block with their new source of drinking water. Tune in and watch the culmination of the relationships between Nina and Callie and the community and the engineers.
Older posts are this way If this message doesn't go away, click anywhere on the page to continue loading posts.
Could not load more posts
Maybe Soup is currently being updated? I'll try again automatically in a few seconds...
Just a second, loading more posts...
You've reached the end.
No Soup for you

Don't be the product, buy the product!

YES, I want to SOUP ●UP for ...