What I learned transitioning from Bain to startup life
Tips and tricks that may be helpful for those who are thinking of leaving professional services for a foray into startup or tech life more broadly
Welcome back! I love making lists to capture my candid observations as I go through daily life, and I recently found this list of things I’d found surprising in my early days at TestBox when I’d just left the world of management consulting.
I alluded to this briefly in an earlier post when I described my transition from management consulting at Bain to working at a fully distributed (remote) startup.
When I started at TestBox, you can only begin to imagine how excited I was to work on a MacBook, be allowed to wear leggings, and…take arbitrary breaks in the middle of the work day without being attached to my phone / Slack / Teams / whatever.
To be honest, I think the leggings and different expectations around responsiveness were just the tip of the iceberg.
I hereby present the top things I learned as I transitioned out of professional services into a startup. Some are obvious, while others are things that I wish someone had told me. I hope these are helpful to those who may be making (or considering) the transition from professional services into tech or startup life.
I learned…
😲 That apparently using emojis is a requirement. I tend to be pretty formal in my written communications and I got made fun of a lot for my reluctance to use emojis in the early days. I’m a changed person now – I use them all over, even in some blog posts… 👀 I used to be so appalled by people who put emojis all over their LinkedIn posts, and here I am doing the same. I will concede…they are pretty fun.
✉️ How to use Google Suite and Slack. This one is pretty unsurprising. Transitioning away from on-premise Microsoft to everything being in the cloud was pretty jolting though. The things that I loved immediately included being able to access things from more than just my work laptop (though that’s not best practice – don’t worry, I don’t actually do that!), better mobile access to apps that we use, and better real-time collaboration and access to ubiquitous commenting features. What was most daunting initially was that everything live synced. We try to avoid individual files on Google Drive and primarily work in shared Coda documents, so it felt like everyone on the team could see my draft work as I iterated and it was scary to feel so watched. Over time, I’ve come to learn that the reality of it is that everyone is so busy with their own work, they’re not staring at everyone else’s Coda docs while they work. Usually.
📅 How to truly optimize my schedule and calendar. No longer being client-facing meant that I could be thoughtful about how I arranged my work week. I was actually in control of my schedule and calendar. Our team-wide meetings are scheduled logically around everyone’s timezones but everything else, whether a 1:1 or other external meeting, is in my control. I sat down early on at my time at TestBox to think about when I’m most productive and blocked off those times as focus time blocks. In addition, I set my Calendly so that external meetings could only be booked in the blocks I allowed. I consolidated my 1:1s and other meetings into certain days and created large focus time blocks for myself. It wasn’t always this magical – this is definitely an iterative process – but I am a huge advocate for everyone who has the flexibility to embrace calendar management. It’s a massive unlock for productivity as well as work-life balance and happiness.
⚙️ How it feels to be measured on output, not just hours worked. Before I jump into how things work for me today, I will say that at Bain, I appreciated that more and more teams were adopting a mindset of “Get your work done wherever and however works best for you” rather than “We must all sit in the office until the work is done.” That said, this usually still meant full work days in the office and then flexibility to wrap up evening work from home. Working remotely at Bain during the pandemic was still very anchored on a regular workday schedule with a similar mentality of being fully available all the time during the day and completing evening work on a predetermined timeline every day. Nowadays, at TestBox, we’re big promoters of a true “Get your work done wherever and however works best for you” approach. Our ground rules are that everyone who is based in North America needs to be online / reachable / generally available from 11am-5pm EST (roughly) for meetings but otherwise, they’re free to work whenever is best for them. I’ve been able to work from Europe and Asia and when at home, shift my days when needed for personal appointments and travel.
💻 How to work with engineers. Early on, we made the mistake of taking how we’d workplanned at Bain and trying to do that process with our team, which primarily consisted of engineers at the time. It turns out how you work plan for a consulting team is very different from how you should work plan with engineers. Project management for software is a whole space of its own for a good reason. My theory is that at Bain, we were very used to working backwards from fixed deadlines and when push came to shove, we compressed or scope cut work in order to meet the deadlines. We didn’t ever work the other way around – with a fixed scope of work and moving deadlines, which tends to be more common when it comes to enabling successful software development. (Cutting scope tends to mean things just won’t work.) The type of work we did at Bain didn’t have hard and fast dependencies, while software development tends to have those.
🏃♀️ How to move quickly. Nowadays one of the things I think about the most is ‘How long are we spending talking about the solution vs actually doing the solution.’ As soon as the former starts to creep up to 50% of the latter, I try to cut off the conversation and say “Let’s just go try it.” It’s okay to try things only to find out they don’t work. That isn’t really an option in professional services and the mindset therefore tends to be measure multiple times before you cut. However, measuring can often be super time consuming. Now, I’m a lot more comfortable saying, let’s spend some set amount of time on this and see if it works. If it doesn’t work, then let’s regroup. This way, you’re not planning for contingencies before they’re needed and can be more efficient. Naturally, there’s a time and place where this works best – it tends to be for quick experiments and patches or temporary fixes. The flip side of this is deciding when to go deep and invest in a proper/better solution for something that’s going to be a certain problem down the road.
Tl;dr
I learned a lot when I left management consulting and started working at a startup. Check out the bolded headings above.
If you’ve made a similar transition from professional services into a startup / tech / other role, what did you learn?