Permission vs Advice

Over the past couple months during my summer work at betaworks, I have tried my best to take a note of what works and what doesn’t work in getting things done effectively in a work environment. What flies and what gets shut down by superiors. What type of projects get buy-ins from cross-functional teams and what do not. Every time I realized or stumbled upon something new, I would take a mental note. A collection of such learnings is what I call my workplace playbook. It’s filled with my experiences and observations. I have decided to convert those mental notes into two blog posts. The posts will be a reflection of both what kind of organization betaworks is and my personal growth and principles.

One of the most important learnings in my playbook is the concept of permission vs advice. When should I ask for permission to start a new project, join an exiting project or run with a new idea? When is it more helpful to ask for advice? Which works the best in what context?

What is more likely to get buy-ins, approvals, appreciation and recognition from my my superiors and teams I work with?

Initially, I thought always asking for permission seems like a no-brainer thing to do. It exudes respect for superiors, job titles and chain of command. It just feels like the right thing to do at a workplace. Especially as an intern.

I would always go “I think doing XYZ would be beneficial, can I look into it?” or “I would like to do XYZ, are you on board with that?” or “I think we should do X instead of Y, can you approve the change?”.

After a lot of experiences and observations, I realized that asking for permissions every time is just a time-consuming and unproductive process. At times, it’s even toxic. I know that sounds counterintuitive.

When we ask someone if we could do a specific thing, we are implicitly putting the onus of taking the ownership of the said idea, project or change on that person. Instead of owning something and proactively holding ourselves accounting for both success and failure of the said thing, we are making someone else’s life harder. When I ask for a permission to do something, I am also implicitly asking my team or superiors to decide if my idea is good enough for us to pursue. This reflects lack of confidence in my own ideas and also lack of research on whether the new idea aligns well with the goals, projects and priorities of the teams, products, or the company.

If the new thing that you are suggesting sounds risky or too radical, they will feel the need to play it safe. They will do a quick cost-benefit analysis in their heads. They are likely to think “If this new project that I approve of goes south, I will be held accountable for not identifying the right hurdles and fire-fighting the obstacles. I already have a lot on my plate right now.”

I am not saying that they will always shut down your initiatives. But, such scenarios are likely to lead to that and cause a sense of skepticism and mistrust in your relationships with others.

Asking for advice seems to be a very effective way of getting things done. When I say “Here’s what I think we should do, what are your thoughts on it?” or “Hey, I want to do this instead of that, I’m looking to get your advice on it.” I have learned that communicating about a new idea or project with such mindset almost always gets a positive reaction, deepens relationships, and avoids wastage of time. When you ask for advice, you are implicitly signaling a couple things. Firstly, you are taking ownership of whatever it is you what to do. This puts the other person in a situation to be able to appreciate your initiative. Secondly, since you are making yourself responsible for the consequences, the other person will feel comfortable giving honest feedback. If the idea is just terrible, no harm is done in shutting it down. If the idea is great, you earn buy-in and get them to participate in your success. Thirdly, by asking for advice, you are inviting constructive criticism. This helps deepen trust in your relationship. You are letting them know that their opinion matters.

I have also noticed that having some tangible version of what you are trying to do would be really helpful when asking for advice on doing something new. I know the feasibility of having a basic version or prototype of sorts varies depending on your role, type of work, resources you have at your disposal, and nature of the organization.

For instance, every week, we brought in mentors and speakers to our office to share their insights with the botcamp teams at betaworks. After a group session, we would have private sessions between each of the teams and the speakers to discuss team-specific questions, problems and products. Since I was the intern, I got the honor of timing fifteen minutes sessions to make sure each team got their fair share with every speaker. So, I would sit in on those private sessions where I would switch between listening to the discussions, looking at the clock, and reading on Twitter. It wasn't an exciting task. At all. During one of the those private sessions in the first week of botcamp, I heard a speaker share an insight that was related to what I was thinking about because of a tweet I had come across a couple hours ago. I instantly thought that insight might be very useful to one of our other teams as well. So, right after the session, I shot that team an email with the said insight. I found myself doing such ad hoc knowledge sharing a bunch of times over the course of a day.

Based off my reading and interactions with others, I knew that a large part of product management was about aligning cross-functional teams and all the stakeholders on a common set of goals and priorities, editing and curating great ideas, and helping individual contributors get their work done on a daily basis. A major way of delivering on those responsibilities involved email communications on the part of a PM.

I had been meaning to explore that role for quite some time. So, one day when I came back from office, I thought to myself “Why don’t I just assume that I am a PM and do what she does?”. I thought I don’t need a title to tell me what I could do. What if I send out a common email to all the botcamp founders along with the betaworks staff talking about the major insights sharing during speaker sessions along with my thoughts on them? Instead of randomly sending out emails to different teams and bothering them multiple times a day, I could just make one long email for collective knowledge-sharing. I had two options. First was to ask for permission for doing this and expecting my managers to make a decision for me. Second option was to just do it and see what happens. I knew that my intention was right and was aligned with betaworks’ goals. What I wanted to do would only help the teams if done right.

So, I just did it the next day. I sent the email out at the end of the day after all the sessions and meetings. It was basically just an unstructured list of insights and my thoughts on various themes discussed. I had listed some teams next to a few points for them to note them closely. I asked all the stakeholders (both botcamp teams and betaworks staff) for feedback and advice on my initiative. I had the fear of looking like a stupid intern sending out useless emails to everyone. Most teams did not get back to me. Some did with encouraging thoughts. Some on the betaworks staff gave me constructive criticism. Since I had already done it and what I did was a bit helpful, I got some good advice on how I could improve it. I concluded that everyone liked the idea but the execution was poor.

Over time, I got better and better at it. The emails got longer. The frequency of emails got higher. They got more structured. I started having group section where I share insights applicable to all the teams and individual sections where I shared team-specific insights. As I started working with the teams, I started sharing meeting notes, feature roadmaps and feedback on product strategy in the same email. After a couple emails, almost every founder started getting back to me with follow-ups and appreciation for my efforts. It also started becoming a tool for building a community. Everyone knew what others were up to and offered to help others on things they have some experience in and started making introductions for their peers. This process helped me hone my email communications, product spec writing skills, and made me a central node for knowledge-sharing in the organization. Founders started setting up individual meetings with me every week to brainstorm ideas, prioritize things, strategize marketing campaigns, get introductions, get product feedback, etc. Overall, I’m glad I took the first step without asking for permission.

There is a big difference between doing something without asking for permission and becoming a reckless loose cannon. There is a big distinction between figuring out where you could add value and where you are doing something just for the sake of starting something and getting some exposure in the organization. I spotted an opportunity to streamline processes in a way that was well aligned with my personal growth goals and every stakeholder’s interests. I knew I wont get it right the first time. I knew I am putting something in writing out there for so many people to see. This could have gone south. People could have said they don’t want unnecessary long emails. But, their appreciation for my effort and intent outweighed my mediocre output. And, they knew that I will be the point person for this and I will be held accountable for its success or failure.

So, yes, asking for advice is much better than asking for permission.

Oh, and, never internalize your job titles. Always respect them. But, never let titles or chain of command limit your thinking. Making people to change my title from an intern to something else is almost impossible. But, making an effort to do whatever it is I would have done with the new title is always possible. This is where influence vs authority comes into play. Thats another principle in my workplace playbook. That’s for some other time.

If it weren't for my experiences at betaworks, I wouldn't have learned this lesson and wouldn't have put in action some principles I had in mind for improving job satisfaction. I can now apply the same principles to all my work experiences and group projects in the future.

It is also important to note that this notion of preferring advice to permissions tends to work well only in environments like that of betaworks. The nature of organization and the kind of work are tied in with how effective this mindset will be. John Borthwick pointed out to me that he was very intentional in creating open and decentralized culture from the get-go. He also said how this culture might not be the best way of growing an organization in other industries like oil, hospitals, etc.

A good reflection of betaworks’ culture was how Matt Hartman agreed on meeting with me at the office about five months ago after I sent him an email. We did not even know of each other until I came across one of his blog posts and started interacting on Anchor. Those small interactions led to a meeting at betaworks. We had a long conversation about a lot of the products betaworks had invested in. We clearly had different opinions on a lot of topics but it was still a fun, challenging and educational experience for me. I ended my work at betaworks with yet another such long conversation with Matt on my last day. That was one of the earliest signals that led me to think that the culture is open enough to appreciate my ideas, unstructured enough to give me flexibility of running with new projects, and established and resourceful enough to give me platform with right access to people and opportunities to grow and add value. Once I had made my mind that I just had to work at betaworks, I kept pinging (bothering?) Matt until he gave in and the rest is history.

The other important workplace practice I have learned is to prefer growing influence to accumulating authority. I will dive deeper into that topic in my next post.