Category: Management

Ownership is the Best Motivator

“It’s not that I’m lazy, it’s that I just don’t care.”

If you’re an Office Space fan, you remember this classic quote that Peter used as an explanation for why he wasn’t putting a lot of effort into his job. While the movie was dramatized, I have felt exactly what Peter has felt – a lack of interest and care for work because I didn’t feel any attachment to it. But have no fear, there are ways to instill feelings of attachment among everyone in your team through an effective company culture.

The key is ownership. I care about my stuff a lot more than I care about yours. And the same goes for every other human being on this planet. When my parents spent money on dinner, I didn’t look too closely at the prices on the menu. But suddenly when it is my money… well hold up on that $25 entree! That’s basic human nature: we care the most about our stuff.

So if that is true, what if we can make it so work is owned by the person doing it? As a leader, there are a lot of effective ways to give your team members ownership over their work:

1. Ask for input and ideas

Instead of force feeding your team ideas or tasks, ask them what they think the organization needs and how they would execute a plan. I bet they come up with something similar to what you already thought of, but the difference is that they feel like they invented it, and thus it is theirs.

2. Assign project leads

Give junior team members lead roles on less important projects. This gives them the opportunity to show you what they are capable of and make real decisions. If they fail, who cares… it wasn’t an important project and it is an excellent learning opportunity for them. They probably won’t make the same mistake next time.

3. Always give credit

If someone on your team does a great job on a project, tell everyone. Publicly congratulate them. It should never be a mystery whether someone did well or messed up. Make it abundantly clear either way.

4. Call out mistakes

It’s a lot more painful when I make a mistake and know I am ultimately responsible for it. Make sure that you team owns their mistakes just as much as their successes. Every mistake is a learning opportunity. 

I execute all of those 4 points regularly with my team at the Entrepreneurs Club. As a result, I am thrilled to have a team of happy, committed, hard working and passionate student leaders.

Bureaucracy Sucks… 5 Ways to do it Well

Let’s face it, bureaucracy sucks. It’s annoying, it impedes creativity and hinders workflow efficiency. It pisses off members of a team and can stunt progress. Yet, as organizations get larger, having defined processes and policies becomes more important. I’ll explain why with a story:

Last quarter my team at the NU Entrepreneurs Club was putting on a large event. We use a web application to send out email blasts to our members, Madmimi, and we deal with lists of thousands of email addresses weekly. A Director on my team wanted to attract more attendees to our event, so he loaded thousands of additional email addresses into our system and sent out a massive email blast. Unfortunately, this resulted in many of the emails being marked as spam and I had to explain to the folks at Madmimi that we did not mean to send “spam” and were not violating the terms of service of the product.

The issue was that when our organization was much smaller, it was ok for anyone on the team to send out blast emails since the lists were a lot smaller and it didn’t make much of a difference either way. But now we have grown into a well known brand on campus with thousands of dollars in funding and hundreds of members. We need to have strict control on our brand and how we interact with our members.  So I took the following actions:

I created clear, easy to understand policies governing how we send emails.

I wrote a brief 1 page document that spelled out very concisely who was allowed to access our email program (and re-distributed the login credentials accordingly), and what specific lists could be accessed by each person.

I wrote a brief email to my entire team notifying them of the policy.

I made sure that everyone understood the new simple policy, and I also transparently stated why we had to institute the policy: our organization has grown and we need to make sure we send only the right emails to the right lists and not make a mistake.

How do you create an effective policy?

1. Make it short and simple: No confusing language.

2. Share it with everyone: Nobody can follow a policy they don’t know about.

3. Use common sense: Only make a policy when the alternative of not having a policy is a worse headache than the policy itself.

4. Don’t make policy for the sake of policy: Do it when necessary, don’t touch anything if you don’t have to.

5. Get everyone’s input: People are more likely to respect a policy that they feel ownership of. Get their insight and have them help create it.

10 Ways to Identify Great Developers

“Developers, developers, developers, developers.”

We all know the quote from Steve Ballmer and the classic video of him showing his support for Microsoft engineers.

Ballmer’s quote holds especially true today as startups and Fortune 500’s alike viciously compete to acquire the top programming talent. This means that identifying and recruiting world class software developers is not only crucial for tech companies, but also more difficult than it has ever been. 

Throughout my experience as a web developer, entrepreneur, and Student Fellow at .406 Ventures, I’ve met amazing software developers. Here is my short list for finding the great ones: 

1. Ability and willingness to learn

I don’t care how much you know right now. Instead, I care how fast you are able to learn new technologies, adapt, and implement them. My partner last summer came into the venture as a PHP novice. The code he wrote the first month was clunky. However, he loved learning to improve the code, absorbing pages of the PHP manual like a sponge. Within months, he became a sharp PHP wiz, re-building the old code in hours even though it took him days to first write it.

2. Passion for problem solving

Writing software is all about solving a problem. Any great programmer must have that innate passion for solving problems, boldly taking on challenges and ultimately conquering the unknown.

Maybe they solve the 6 Rubix cubes on their desk in under a minute or they spend every morning manipulating a Soduku puzzle. Either way, having a knack for problem solving in an efficient, salable, and manipulable way is paramount.

3. Logical and mathematical thinking

At a very basic level, any software program is a series of commands (logic) that goes through situations and takes some sort of action based on the situation. For example: IF it is raining THEN I’ll take an umbrella ELSE I won’t take an umbrella.

Great developers will many times think, speak and act in similar ways that they program. If I videotaped some of the arguments my CTO and I had, I bet we could easily transcribe them into basic logic arguments and turn them into a web app. Look for people that love math and logic, those skills translate well into development.

4. Flexibility

If a developer seems married to one programming language or stack, run away. It might be Ruby on Rails today, Python and Django tomorrow and picking apart some Node.js or Scala next month. Once you understand the fundamentals of Object Oriented Programming (OOP), it is fairly simple to go in between these different languages. You want someone that is flexible, a jack-of-all-trades in the programming world. They don’t have to start out this way, but must have the willingness to learn and explore at a rapid pace.

5. Readiness to re-code

When I was was first learning to program, it drove me nuts that I had to constantly re-do work. But that is the nature of the beast: as you learn and get better, it is essential that you optimize whatever code you are working with to function at its best, and unfortunately that usually means scrapping old code and starting from line 1. Any experienced developer knows this, and they need to be ready and willing to re-code when necessary without grumbling about it. I was a grumbler, and I learned fast the error of my ways.

6. Being a team player

Every engineering team is just that, a team. There are multiple developers working towards the same goals and writing different parts of the same application.

That means you want someone who doesn’t mind picking up where someone else left off, deciphering someone else’s code or comments and ultimately working in a collaborative environment. Developers that go with the attitude of “mine mine mine!” are probably not going to be a good fit.

Make sure they take this very seriously, even if it’s a team of 1 right now. 

7. Playing well with non-techies

Any strong startup team is not just made up of developers. There are designers, business people, and investors, just to name a few. The engineering team must be comfortable working with other stakeholders in a cross disciplinary environment. There will be project managers and product folks suggesting ideas for the product, which at times might be unfeasible or simply wrong.

I want to hire the engineer that doesn’t criticize or shrug off a flawed proposal, but instead takes the time to explain the problem to decision makers that might not have a technical background.

8. Code formatting

When most developers start out, their code looks like crap. Nothing is indented, views mix with business logic, and the madness goes on. A good developer quickly learns that formatting code well so it is readable and properly commented is very important. When responsibilities shift, it makes a world of difference for engineers to be able to look at code and understand exactly what it does and what other pieces of code it interacts with.

9. Emphasis on documentation

In addition to clean formatting of code, having proper documentation can make everyone’s lives a lot easier when code needs to be reviewed or edited down the road. Keeping a log of every function (along with its parameters), file, and database table is a great habit to get into. It is not as annoying as it sounds, and the consequence for not doing it is a guaranteed headache when you have to sort through 50 files to figure out what 5 little lines of code do.

10. A fun, hardworking, good person to be around

I follow the golden rule of “do not work with assholes.” I don’t care how much of a code master you are, if you’re not nice to other people in the company, if you put others down, or don’t respect authority, then you won’t work with me. I’d much rather train a hard-working, smart, and fun new developer then a self-labeled expert that is rude or arrogant. Choose your team with this rule, hire slowly and fire quickly when there is a culture problem.

If you need to figure out how someone’s going to treat the other people in your company, take them out to a meal or two. When you get a chance before you order, take the waiter/waitress aside and ask them to bring out the food either late or slightly incorrect. Then, see how the engineer reacts to the situation. Do they complain or talk beyond the server’s back? Or do they politely communicate the problem like a nice, understanding human being?

Every startup is going to have ups and downs, and if someone loses their cool at a minor issue in a restaurant, you might not want to be rely on that person when it’s crunch time and you’re a month away from running out of money. 

Are you ready to become a great developer? Awesome! Here’s what you should do:

  • Get on Codecademy: It is the hands down best place on the Internet to learn how to code, co-founded by my friend Zach Sims.
  • Get some books: I recommend ones like the PHP Cookbook that walk you through every key area of the language and provide a ton of real world examples (with real code) to play around with.
  • Start hacking: Play around with code. Make up an idea for a mini application and hack it together piece by piece. It’s going to be clunky – that’s ok, you’re learning!

Good luck!

Thanks to Kirill Klimuk and Drew D’Agostino for their input on this post.

Can you Read? Technical and Financial Literacy

2 Things Business Students Must Know

Managers in today’s economy cannot just be good at one thing. On the contrary, they need to have an exposure to almost every facet of the business that they are managing if they are to succeed. Does that mean you have to be a network engineer in order to run Cisco Systems, or a chef in order to run Nabisco? Certainly not. However, it’s tough to manage what you don’t know. Last year in the NU Entrepreneurs Club, I was the Director of our Startup Challenge, the largest division of the club. This year as President, I manage that Director, and 23 others. I know what they have to deal with because I did it myself before.

I believe that for any business-oriented student graduating today, in addition to whatever your major concentration is in business, you need to be literate in two key areas: technology and money. A lack of understanding of either is a gaping failure point for an organization. Let’s look at each one:

Technical Literacy

This means that you can talk the tech talk. Do you have to be the CTO? No. But, you need to understand the language, the acronyms and the terms that engineers use. You need to be comfortable speaking to engineers and have a solid understanding of how they think and how they work. You should be able to approximate about how long a technical project will take, and about how much it will cost. Advantages:

  • Earn respect from the engineering team… engineers want to see business people who at least have the desire to understand tech
  • Pay the right price for tech projects because you understand what it takes to complete them
  • Gain opportunities to leverage technology that you understand to increase efficiency and reduce costs in your business

Financial Literacy

A balance sheet can be confusing. Do you know how to calculate comprehensive income or loss? Your company just bought a new server – how should we deal with the cost of that asset and how should we depreciate it? These are questions that should not be reserved for just your CFO or Controller. Advantages:

  • Ability to talk to finance and accounting teams and understand their needs 
  • Insight to know when there is a financial problem in your company, not enough cash flow, etc.
  • Skills to review a company’s financial statements before your join the team to ensure it is in good fiscal health

Ready to become technically and financially literate? Great! Here are the action items:

Clarity as Clear as Glass

“Assuming makes an ass out of you and me.”

I make it a point to focus on clarity with my team. This plays off the old saying that “assuming makes an ass out of you and me.” I may have an idea for a project, or a specific deliverable that I need someone on my team to take care of. If you want something done right, you need to be explicitly clear with exactly what you need, the format you need it in and the deadline. I use bulleted lists, bold things and use key words like “action items” and “deliverables.”

If I am on a team and get these kinds of instructions from the project manager, there is no excuse to get it wrong, because it is so drop dead obvious, and everyone knows it. 

It’s really easy to be clear. Use the following guidelines when outlining instructions:

1. No big words.

Use simple language that is easy to read and digest.

2. Don’t write long paragraphs.

Bulleted lists are your best friend.

3. Bold what is important.

People’s eyes will go right to it.

4. Format documents.

Use tables, use visuals. My professor and serial entrepreneur, Bruce Russell, explained it best that the important stuff should jump right off the page.

5. Be careful with acronyms.

I only use acronyms when my team either knows them, or I want my team to learn them by searching on Google.

6. No extra information.

Tell people what they need to know. Nothing less, nothing more.

What are the advantages of clarity?

  • Less mistakes
  • Less frustration
  • Faster delivery times
  • Things get done right the first time
  • Happier team

So, next time you are writing a Goliath email that seems more like a Harry Potter novel, take a step back and ensure that things are concise and the important information is abundantly clear.

5 Ways to Be a Great Mentor

Especially in the world of entrepreneurship, having great mentors and being a great mentor is crucial. Mentors can act as guides for a young entrepreneur, helping them avoid classic mistakes, making key introductions and serving as a teacher far after college graduation day.

Over the past few years I have had multiple mentors, and been a mentor myself to others. As President of the Entrepreneurs Club, a key part of my role is to act as a mentor to all 640 of our members, and especially to the younger students leading the club on our executive team. On top of that, I am honored to have quite a few great mentors to guide me, such as Graham Brooks at .406 Ventures, Gordon Adomdza at Northeastern University, and Ken Coleman, co-founder and former EVP at TimeTrade Systems.

So what makes a great mentor? There are varying degrees of how intense the relationship can be. In some cases, it is just a check in once in a while and an open line of communication to ask questions. When I play the mentor role, I like to take a very hands on approach. Especially for my younger colleagues, my goal is to give them tangible feedback, advice points and action items that they can use to advance their careers. More specifically, I suggest a mentor does the following:

1. Be critical

I call my mentees out a lot, anytime they make a mistake. I clearly explain to them where they fell short and how they can improve. It’s much better they hear this from you so they can improve for when it counts.

2. Focus on soft skills

This means proper business acumen, wording in emails, etc. I am constantly reviewing sent emails / any written doc (ie a resume) with my mentees and making suggestions for improvement.

3. Make introductions

And make a lot of them. Build up your mentees’ networks. I make many intros via email and suggest my mentees set up meetings.

4. Guide, don’t do

Be sure to make suggestions, but never give orders and never do the work for your mentee. I always use the phrasing when making a suggestion "I would consider doing X"

5. Suggest tangible action items

I always provide, in bullet list format, clear ideas for my mentees to consider executing to contribute to and advance whatever they are working on.

Ultimately, the relationship will depend on the time, flexibility and personality of the both the mentor and the mentee. If you want to find a mentor of your own, there are plenty of great programs in Boston to help you, like Sean Lindsay’s Founder Mentors or Northeastern University’s venture accelerator, IDEA.

Are You Afraid of the Dark? Risk Management 101

Last weekend I watched the Hills Have Eyes 2 on DVD. Knowing my policy on horror movies (stay away from them), this was admittedly a poor choice. That night as I stared into the blackness of my dark room and I tried to fall asleep, all I could think about was the blood thirsty mutants. As I thought about this more, I realized there is a distinct link between my mutant fear in the dark and risk management in business and entrepreneurship.

Put simply, we fear the unknown. The darkness is scary because we can use our imagination to decide what might be there. An unknown represents a risk and this induces fear. When there is light, we have confidence because we can see exactly what is going on. Unfortunately, the business and especially entrepreneurial world is one giant dark room, filled with risks with unknown outcomes.

The key to mitigating risks (and allowing yourself to fall asleep and not get attacked by desert mutants) is two fold.

  1. Outline potential outcomes – if (A) happens, what is the worst result? How can I plan to make it better?
  2. Acquire more intelligence. Analyze data, look at past examples and trends. Shed some light on the darkness.
  3. Suck it up and move forward – entrepreneurship is a risky business.