Tag Archives: Software

OSU CS467 Update

Wanted to provide a brief update on my CS467 class at Oregon State. This week, we hit our midpoint, so I’ve created this fun demo video to talk more about where the team is at, what we’re working on, and what we have left to do.

In my video, I call this out, but one of my favorite dynamics of our group is our weekly group programming. I’ll dive more into how our group is really using this to drive our project forward.

Group Programming

Each week, my teammates and I meet for 2-5 hours across 1-2 meetings. The purpose of these meetings is to give updates and brainstorm, but it’s turned into one of the best places for us to knock out key initiatives.

Our project involves 15 rooms and a parser to navigate between those rooms and perform actions on objects within those rooms. This makes it incredibly easy for each group mate to own 5 rooms and the functions that occur in their rooms. However, we quickly recognized that there was some shared navigation and other verbs that crossover between our rooms.

In the first week we started coding, we transitioned our group meeting from an update meeting to an actual working session on navigation. Then our second meeting to a working session on our parser. These incredibly important brainstorms and group programming sessions has allowed our group to not spin our wheels independently working towards the same solutions but rather put our heads together and knock out things much more quickly.

These group programming sessions have been fundamental to us staying ahead of schedule and have made it so much easier for each team member to knock out their sections so much more quickly. Because we’ve worked as a team to discuss these things and all get on the same page, there’s no confusion on how to use these overlapping functions when we begin to work independently.

Implementing Group Programming

Though this is likely not the perfect solution for every project, I’ve found it incredibly valuable and a great reminder that taking the time to source feedback and brainstorm with others, though sometimes time-consuming, can actually allow a team to operate at a much higher efficiency.

This also doesn’t have to be independent to the actual backend or programming. I can think of several scenarios in my own work in Revenue Operations where I’ve been presented a problem, gone about executing a solution, and then been sent back to the drawing board when it didn’t quite meet the moment upon roll out.

There’s a lot more people involved in workplace solutions than just the programmers, developers, and project managers. Though you may not want to bore a salesperson, customer or other end user with the actual execution, it’s so critical to consistently be re-engaging with these parties to make sure you’re staying on track with the end goals and not getting too deep into just making the code work.

What’s Next?

The rest of our project timeline is dedicated to knocking out our individual portions independently and using our group time to improve the game’s usability. I’m feeling really confident about where we’re heading and even more confident that the dynamic we’ve built as a team is allowing us to do that much more quickly.

I’m really learning a ton in this course and surfacing some new ideas for collaboration that I’d really love to take back to my workplace. Group projects can be incredibly difficult, but I’ve been pleasantly surprised at how well our team has worked together and want to scale that dynamic into other projects I’m working on outside of school.

Building Solutions that Scale

For the product nerds out there, “building solutions that scale” might be a phrase you here rattled off regularly. In my sales background, this was not a phrase I really heard until I joined the LinkedIn Global Sales Organization in 2018.

At LinkedIn, they called this concept “Leverage”. It was one of our key performance metrics not only for our technical folks, but throughout the entire organization. You were expected to not only hit your result and be a leader on your team but also to scale your success 10x within the organization to bring your colleagues up with you.

Being pushed to apply this principle outside of my engineering background fundamentally changed my success at work and beyond. I’m writing today in hopes of convincing others to also adopt this mindset, especially those in Sales.

So you’re an Engineer…

You’ve probably heard this mindset a lot then. Every single course I’ve taken in computer science and engineering focuses on the importance of understanding the customer problem, building “clean” code / solutions, and providing adequate documentation for the end users as well as future engineers. To build a solution that scales these are all vital.

Understanding a customer or end user’s problem, needs, and wants is always the first piece. The more you know about the full customer profile, the more you are able to predict future needs. This allow you to build your solution in a way that it can grow with the customer vs. fixing it for today’s problem.

Building “clean” code or solutions stems from that clear understanding. I always think back to the old trope from sitcoms of the husband refusing to hire the handyman, fixing something with duct tape, then ending up with far more damage in the end and a bigger bill from the handyman. Solutions to complex problems can be the same. Build and fix your code in a way that allows you to continue upgrading and using your initial framework. Otherwise, you may end up throwing out the whole kitchen sink instead of just replacing the pipe when someone new to the problem tries to fix something.

This leads into the documentation piece. Building solutions that are well documented helps not only your end user utilize that tool more effectively but also helps your future product team maintain and upgrade your solution well past your time working on it.

As an engineer, the one thing more satisfying than seeing your solution put into practice is seeing your solutions evolve and improve well into the future. Keeping the customer problems in mind, providing clear fixes to those problems, then documenting that for future users and engineers provides your solution the framework it needs to scale and reach this goal.

So you’re a Sales rep…

If you’re reading this as a Sales rep, you’re probably like, “I’m not programming or building solutions – what does this have to do with me?” I thought the same thing, so I encourage you to think about what you’re doing every day as a Sales rep. You’re consistently solving customer problems, and you’re also likely working with numerous other reps.

The quickest way to make yourself indispensable as a Sales reps is to adopt this mindset and find ways to scale your solutions for your customers, for your own sales process, and beyond by 10x.

Let’s think about customer solutions first. Finding a way to perfect your pitch to a science is scalability. Creating a sales pitch that fits an industry, role type, persona, customer pain point, etc. allows you as the rep to then take that pitch and find several more customers that fit that same profile and sell them similarly. Though you should treat each of your customers as individuals, you should also find ways to pitch your solution to different personas. This can expand your addressable market, increase your productivity, and improve your confidence in your solutions. When you sell one customer, start thinking about how you find 10 similar customers to sell in the same way.

This leads us into productivity. If you want to be the best sales rep as well as help those around you be their best, you should constantly be thinking about how you do more with less. Sales enablement tools and CRMs exist solely to scale Sales processes, but there’s still a long way to go in scaling the great things that great sales reps do. My entire role in Revenue Operations exists to do just that! Find ways to take your best customer interactions, most productive resources, etc. and use them with every customer interaction. This will save you time, create stronger customer interactions across the board, and make you a lifesaver for the entire team you work with.

There’s an entire industry built around scalability in Sales. Finding ways to implement it day-to-day, even as an individual rep, will make you a top performer and an indispensable resource to your entire organization.

Focus on the Future

Sales teams, Product teams, and organizations as a whole need people who can think for the future and build solutions around that. It will not only make you more effective in your current role but will also set yourself and others up to take your successes and improve on them well into the future.

If you can take one thing from my “jack of all trades” experience, I hope that it is to use the “building solutions that scale” mindset and apply it to every role and every situation you encounter in your day-to-day. You’d be surprised how much time and energy it will end up saving you in the long run, despite your role.

A Salesperson’s Guide to Software Development

Welcome to my first ever “Decoding the Developer” blog post! This passion project has been a long time coming, but I’m excited to finally be kicking it off.

In this first post, I want to dive into the inspiration behind this blog, and the journey I’ve been on to get here. To put it simply, my mission is to merge my own technical and sales backgrounds to help my fellow salespeople walk a mile in the shoes of their product and engineering counterparts.

From Small Town to Corporate America

Don’t worry – we’re not going to start at my childhood. This was just an excuse to share a cute picture from the 90s!

Growing up in middle-of-nowhere Illinois, I never could have dreamed of studying Computer Science or working in Sales. Those career paths just weren’t paths that most adults around me in my small town had taken.

This gave me quite the identity crisis in my first semester of Bioengineering at the University of Illinois. I was surrounded by 54 kids in my program that had taken every AP course known to man and learned much more than Microsoft Office in their high school technology curriculum.

I took my first true Computer Science course that year and struggled my way through it forcing every new college friend to teach me everything they knew. It wasn’t until my junior year that I found my own love for the study. A friend taught me Python, and I got to immediately put to use my new programming skills the very next semester in a Medical Device course I was taking.

It was a little late to switch majors, so I finished my degree in Bioengineering, vowed to keep learning to code, and jumped into an Inside Sales role right out of college at Wolfram Research (yes – like Wolfram Alpha). It was selling Mathematica powered by Wolfram Language that fueled my hunger to go get that Computer Science degree. Enter Oregon State Ecampus.

Marrying Sales and Software Development

It was when my SHPE (Society of Hispanic Professional Engineers) Penpals came to visit University of Illinois that I finally pulled the trigger on going back to school. Their own passion and excitement to be “a woman in engineering just like Sam” inspired me to follow my dreams as well. Working full-time, Oregon State Ecampus was the perfect fit!

I’ve spent the last 4 years continuing to hone my Sales skills and putting my Computer Science education to work to be the most technical Salesperson on every team I’ve been a part of. With an end goal of getting into Revenue Operations, I soaked up all the programming, project management, and general technical skills that I could.

Continuing to marry my more technical education with my work experience helped me create so many resources that improved not only my abilities in Sales but also those on my team. I was able to create reports, scale processes, and do so much more based on the technical skills I was learning in my Oregon State courses.

I finished out my direct selling career at LinkedIn and finally made the leap into Revenue Operations, a space where I felt like my unique skillset would allow me to better the lives of those around me, move up quickly, and leave a lasting impact on the Sales teams I was part of. I joined Bluecrew, a small startup of just under a 100 employees, and quickly carved out a special place for myself as the Senior Revenue Strategy and Analytics Manager just a year after joining.

Decoding the Developer

This brings us to current state. I’m taking my Capstone course while serving as a leader for the Revenue team at this growing startup. Consistently, I’m interacting with both our Product team and Revenue team trying to communicate and escalate improvements for our customers to a Product team with very limited resources.

In doing this, as you can imagine, there’s always a light tension of Sales wants/needs and Product team capacity. I’ve even found myself frustrated or confused due to slow progress or mismatched expectations with our cross-functional partners. It’s in these frustrated moments, that I often try to take my Revenue hat off and put back on my Product Manager hat.

Courses like Capstone with projects that force students to be not only the Developer but also the Project Manager and even sometimes the customer have completely changed my work behaviors. I’ve improved not only my effectiveness in my own role but also improved my relationship and communications with my partners on the Product and Engineering side.

Why start blogging about this now? I’d like to use my current Capstone project and future projects to help my dear friends on the Sales side get a simplified look at what goes on over on the Product and Engineering team. It’s my hope that this will not only spread the compassion I have for my Product Manager and Developer friends but will also help other Sales folks communicate their concerns, needs, and product visions more effectively on behalf of their customers as well as themselves.

Join me in “Decoding the Developer: A Salesperson’s Guide to Software Development”. It’s going to be a fun journey!