Tag Archives: Management

7 Techniques to Improve Brainstorming within your Engineering Team

By Frances Advincula 

We all know that a great engineering team is comfortable with a lot of argument, a lot of debate, a lot of brainstorming. The diversity of thoughts and opinions always helps make a better product. A complicated problem half of the team has been try to solve for the last day might be easily solved by a fresh pair of eyes equipped with a different set of experiences.

I’ve been thinking about ways engineers can brainstorm better when I came across a wonderful book, The Human Side of Managing Technological Innovation: A Collection of Readings. There is a great story in there about how the Alpha team at Digital Equipment Corporation (DEC) overcame their obstacles as they created the Alpha chip (full story here). I thought I would share the lessons I learned from that read, as well as a few other strategies suggested by McKinsey and Company, a video from Second City, as well as Marissa Mayer’s lessons learned from years at Google that might just make us better engineers through improved brainstorming.
1. Build a culture comfortable with failure (with a “Yes, and…” attitude). In a nutshell, if you aren’t failing, that means you aren’t doing something worthwhile; you are not pushing boundaries, and to make people willing to risk more, you have to make them know to their very core that making mistakes is okay – as long as we learn something constructive from them. Take a clue with PBS who even included failure in their performance metrics as positive criteria (If you are interested, the article “How I Got My Team to Fail More” by Jason Seiken can be found here). It is also a cornerstone of what made the Alpha team at DEC successful. For example, the Alpha team held regular “circuit chats” where engineers can come in and bounce around half-baked ideas, and even “Circuit Design Confessionals” where engineers can admit design failures for the sake of others learning for their mistakes!

2. Learn to work with constraints. According to Marissa Mayer, formerly a Vice President at Google and now CEO at Yahoo, “Creativity loves constraint.” Similarly, the Alpha team at DEC didn’t just set out to build just any great technological feat – they wanted a chip that would beat Intel, and would x times faster, etc. than the current industry standards. Most importantly, it had to be compatible with VAX technologies, which is what ultimately convinced management to fund their project.

3. Know your organization’s rules. To build upon the previous point, to be high performers, we must not brainstorm just for the sake of it. We must practice brainstorming for a purpose. Therefore, work within your company’s absolutes. Don’t waste an entire day talking about solution X when you know for a fact that management will not approve of solution X. For example, if we know that we absolutely cannot ship without doing regression testing, we cannot spend time talking about alternatives to regression testing.

4. Throw away the org chart. To generate the best ideas, you want people who know the subject matter, those who have worked the trenches. You should not pick people because of their status or political power. That is one of the key strengths of the Alpha team. They practiced egalitarianism – everyone had a say, everyone respected each other’s opinions, and no one was afraid to speak their mind.

5. Subcategorize groups. Again, to build upon the previous point, although we can be utopian and just mandate that everyone speak their mind regardless of their position or career level, we have to be realistic. In short, we have to help cultivate an environment that fosters that culture. McKinsey does this by dividing barnstormers into groups of 3-5. Why, you might ask? Research has shown that this is the optimal number where people feel comfortable speaking out – too much and the more assertive people tend to drown out the rest of the group. Furthermore, McKinsey suggests that we group subject matter experts and those that tend to turn down ideas into their own groups. The reason is that some tend to just accept SME opinions because they blindly assume the SME knows what he is talking about – which is not necessarily the case.

6. Encourage a sense of ownership. Set up your project teams in such a way that people can work on the things that they resonate with the most. No one is going to invest their 200% on something they do not believe in. In the case of the Alpha team, they were actually two small groups which merged together after their projects were cancelled. Therefore, everyone worked hard on the new project because they wanted to prove their ideas right, to prove management wrong. Whatever motivates your team, find it and make sure everyone is invested in the idea. Otherwise, why would they care? Why would they give it their all?

7. Have fun. Lastly, always keep a collaborative, fun, environment. This type of environment fosters trust among members, helping them be more comfortable about speaking up. It helps cultivate a culture of open communication where engineers know they can walk up to another person’s desk, where they know they can ask each other for advice really quickly in the hallway. This results in a more thorough osmosis of information from person to person, allowing for ideas to be bounced around and built upon more effectively.

Helpfulness: A Key To Unlocking Leadership Responsibility

“Helpfulness: A Key To Unlocking Leadership Responsibility” by Karen Catlin

The best piece of advice I received when I started managing people? That my job was to make my team successful. Over time, I built on this advice, realizing that I also had to make the teams around me successful. This approach was key to unlocking more leadership responsibility. Let me explain…

At one point in my career, I was the only program manager at my software company, responsible for scheduling and organizing the work needed to create a successful product. Given that I hate reinventing the wheel, I was careful to keep track of what I did, improving how I got the job done with each project we released. When other teams started hiring program managers, I put together a kit of my best practices to help them learn the ropes and be successful. I wasn’t expecting anything in return, but, in hindsight, creating this kit was critical to my career. My personal brand became linked with strong program management, driving consistency across business units, and “dotted line” leadership of people outside my direct team. As a result of helping others, my leadership reputation and responsibilities grew.

While I like to think of myself as a generally helpful person, I’m a novice when compared to Adam Grant, a professor at Wharton. I heard about him from my friend Lise, who pointed me to a NY Times article “Is Giving the Secret to Getting Ahead?” The reporter followed Grant during a typical day, where students sought his advice as he walked across campus, stood in lines outside of his office hours waiting to get a chance to talk to him, and sent him hundreds of emails asking for help or thanking him for something he had done for them.

Adam Grant practices “extreme helpfulness,” giving his time and advice to everyone who asks for it, regardless of how busy he is. He’s truly generous with his time, without expecting anything in return. Does helpfulness pay off for Grant? According to the article, yes.

“For Grant, helping is not the enemy of productivity, a time-sapping diversion from the actual work at hand; it is the mother lode, the motivator that spurs increased productivity and creativity.”

Creating the kit for program managers was my mother lode. After that experience, I wanted to help my co-workers even more. I started mentoring individuals to share my experience and advice. I continously updated the kit and encouraged others to contribute to it. I built shared engineering services teams to help other groups across the company create their software products. Like Grant, helping others increased my productivity and creativity, along the way making me a better leader.

How did I transition from simply being helpful to being recognized as a leader? There is an important distinction to make. Making people around me successful does not mean that I did their work. By contrast, I shared my experience while helping them identify their own strategies for success. If you want to turn helpfulness into leadership, consider the following:

  • Teach others to fish. If co-workers ask you to track down all the difficult bugs (because you’re so good at it), turn it into a leadership opportunity. Identify the 3-5 steps you take to reproduce any difficult bug, share it in an email or internal blog, and offer to give a casual talk about it at your next team meeting. Bonus points for giving a lightening talk about it at a local tech Meetup.
  • Embrace lessons learned. Offer to run a post-mortem or review of a customer meeting, a sprint, or a system outage. Identify things that went well and things that need to improve. Create best practices.
  • Tell stories. Every challenge that you or your team faces is fodder for a story that can guide future behavior and become part of your company’s lore. Look for opportunities to be the keeper of this knowledge and to share it via storytelling.
  • Share credit. Be generous with thanking others for what you learned from them or what they contributed to the projects you weave into your stories, your lightening talks, or your best practices.   

 

The next time you help people around you be successful, consider using one of these approaches to build your reputation as a leader. They’ve worked for me, and I hope they help you as well. If you want to explore this topic further, please consider joining Femgineer Friends, our bi-monthly group mentoring program. We meet online to discuss strategies for developing leadership skills and advancing your technical career.

Do you have other ideas for transitioning from simply being helpful to being recognized as a leader? Please leave a comment; I’d like to hear from you!

 


Karen Catlin, a former software industry executive, is now a leadership coach and the latest member of the Femgineer team. She is passionate about helping women have successful careers in tech. She’s also the author of “Use Your Inside Voice“, a blog about the intersection of leadership and parenting; a version of this post was originally published there. Find her on Twitter at @kecatlin.

Enhanced by Zemanta

Retaining Startup Engineers

In my previous post I focused on the key issues to think about when recruiting a startup engineer.  In this post I’d like to shift focus on how to keep them.

Engineers jump ship early for various reasons, its usually a combination of the following three: instability in management, unclear path to an exit, and work that is mindless and unyielding.  But there are those who stick around even if there isn’t an end in the near term, there are periodic shakeups in the organization, and they’re well past their vesting initial vesting period.  The reason they stay is that they are enjoying the work, being challenged, and experience the impact they are making on users.  They also have a manager who has given them the support they need to advance in terms of projects, and believes in quality of the work they are doing.  So how does an engineering manager retain talent?

Prized Projects

Managers should realize that if they have engineers on their staff that have a decent track record, have been at even one successful startup (including the present one), and can bang out code on a couple platforms then chances are they are going to be wooed all the time!  You can’t blame recruiters for trying to covet your prized programmers.  Instead you’ve got to learn to understand each of your engineers and continue to motivate them.  This is hard to do in a startup.  Why?  Because as a startup manager your time is limited and you’re under a lot of pressure to produce results and end up prioritizing it over making sure that everyone on your team is satisfied.  And even if you wanted to please everyone there are only a limited number of juicy projects to work on.  If you can’t promise a project don’t.  But if there is a chance to break up a project into parts, and divvy it up that might be the way to go.  That way you’re not playing favorites and you’ll benefit from building redundancy in the knowledge base over time.  Remember startup engineers don’t want hand-me-down projects, i.e. they don’t want to feel like someone else has built everything and now they just get to maintain it.  They want to be part of the creation phase, and if you can give them a slice of it then they’ll stay motivated because they’ll feel like you listened and cared about advancing their experience and skill set.

Communication and Coding Style

Most people speak up for what they want.  Some just go off and build stuff.  While others sit around and wait to be asked if everything is ok and are afraid to go off on their own.  As an engineering manager its important to figure out what your engineers’ coding and communication style is right off the bat.  Its perfectly ok to ask people whether they like having freedom to manage their own projects or need a more disciplined task master.   You also need to know their preferred work style.  Some people like to come in late and code into the night while others may be morning people and want time off to relax in the evening.   There are those who code away in noisy environments while others need a quiet room to think in for a few hours a day.  There are also some who work best if they just work on a single project and others like context switching or working along the entire stack as opposed to just front or backend development.  These are the types of questions an engineering manager needs to ask during the hiring phase to gauge their candidate’s personality.  It will of course change with time, which is why its important to do a monthly checkup at the very least.

Checkups

I’ve been on both sides of these, and frankly its awkward for everyone.  The manager sits there and first wants a status update then moves onto pressing issues, and then finally asks the engineer how things are going.  At which point an hour or more has gone by and everyone is exhausted.  Checkups should not be status updates.  A manager should know what the status is if they’ve reading checkins and tracking bugs.  One-on-one time is meant to place the engineer’s concerns first.  Find out if they’re stuck on something, if they’ve been exploring a new technology, how they like the project so far, or if they have any concerns with a member of the team or the company.

Rewards

Yes there are limited funds, so monetary rewards aren’t always possible.  If you can’t afford to give someone a raise then at the very least give them praise!  There are a lot of other ways to incentivize people: conferences, giving them time to learn a new technology, showcasing their latest achievements in front of their peers, and for heavens sakes tell the founders, investors, and management about the stellar job they’ve been doing!

Remember in a startup emotions runs high especially if there are periodic fires to fight.  If there is one unsatisfied engineer then chances are there are more or there will be soon.  As a manager your time is limited and its hard to motivate everyone on your team all the time.  But that’s another reason why you have to make sure the team dynamic is one where people help each other out.  Collaboration isn’t just about getting things done its about building a culture that can last through the fires.

Enhanced by Zemanta