8 Weeks at Crowd Favorite

I'm sure someone will question whether sharing this “inside look” into my first eight weeks at Crowd Favorite should happen on my personal site or on the corporate blog. I'm sure others will question whether it should be public at all.

But the truth is that you've been with me on this entire journey, so I thought it might be an interesting read.

So here's an inside look at the 8 principles that have driven my focus over the last 8 weeks at Crowd Favorite.

1. Move fast and slow at the same time

There were several different leaders among the staff that I joined. I quickly removed the responsibility of leadership from many of them.

That's initially jarring and not a fun thing. I know it.

But leadership isn't a power thing. It's a service thing.

And it's not neutral. It's opinionated.

Leadership has bias. There's a right and wrong way to do things.

And you can't have leaders leading until they understand the new playbook. And every time you bring in a new coach, with new plays, you need to make sure that the leaders in the organization know the plays.

You also need to make sure they're (still) signing up for leadership under the new management.

I expect every leader on my team to serve those around them. It's an inverted pyramid with those with the most leadership authority serving the most people in the organization.

So while our executive leadership didn't change, most of the team leads were left with titles (and their salary) but had their additional responsibilities put on hold.

I'm slowly giving them back those responsibilities as they understand the new playbook. It's a slow process.

And there's always testing and evaluation.

But none of this is hidden. It's something I articulate quickly and clearly so that everyone knows what's going on.

Eventually, and it will take a few months, people will hear my mantras in their heads and be able to function from these principles without me repeating them regularly.

2. Project profitability is for everyone

In many companies I've seen, helped, and watched, I've noticed a perplexing trend. It's the desire to shield everyone – from developers to project managers – from the everyday stress of running a business (regardless of size).

I don't hold that this is a good thing. I believe that our front line staff make more decisions per day than anyone else. And so to make those decisions without any context can be dangerous.

I'm not saying every developer and project manager needs to know every nuance of your GL. But I am saying that I think people should be aware of the profitability index of their projects.

This has meant new reports that I look at every day, and new data that project managers collect every day. But it's also meant that new discussions are happening before projects get started.

I use a set of algorithms to rate every project and it's the mechanism I use when I meet with our PMs daily to pick which projects we'll talk about.

And it's not only the bad ones. Sometimes talking about a really healthy project can help others think about their own projects in a new way.

3. Do fixed bid projects well

The challenge I faced, upon entering the new Crowd Favorite, is that there were two cultures working simultaneously but in two different ways. The old Crowd Favorite did most of their work on a Time & Materials basis. The old VeloMedia (the company that bought Crowd Favorite) did work on Fixed Bids.

These are really different approaches – with benefits to each.

In picking one, I knew that someone would have to learn something new. Our exec team preferred fixed bids, so that's primarily what we're doing. And in making that selection, we've had to work out ground rules for how to deal with scope requests, requests for additional meetings, and more.

Picking either one takes work.

But the work starts after you pick one.

Because then the real work starts – from how you create bids and quotes, to how you respond to scope changes, to how you prep customers when a deadline is looming.

It's a process and we're getting better at all of this every day.

4. Get up to speed in 2 days

You knew this would be on the list, right? I mean, isn't it a debate in every company.

The logic goes like this: If we build our own framework, and teach everyone to use it, then they'll all be faster and things will be awesome.

I know. I've said it. It's the call to build internal tools.

So it was no surprise that I stepped into a company that had a lot of internal tools – some of which I will support and others that I won't.

Gather any group of engineers and they'll quickly dream up tools they could build. And with the success of basecamp, the dream to monetize the tools looms everywhere.

But I have a rule. It's helped me for 20 years. So I've introduced it to our team. And I'm sure some folks have disagreed with it.

In fact, you may disagree with it.

But here it is. It's called the two-day rule.

If a person can get up to speed and be productive with a tool in 2 days, I'm all for using it. If it takes longer, I won't mandate it.

Notice I don't say you can't use it. I simply won't mandate that everyone must do it.

Because the opportunity cost is too high.

If you have internal tools that take weeks to learn, just to be productive, then you're giving away potential revenue.

You also have to count the cost of tool upkeep. And the opportunity cost there too.

This has impacted what I've invested in. It will impact what I further invest in. And it impacts what I allow others to invest in.

That said, I'm also investing in some new tools (via purchasing rather than building) that developers will be able to learn quickly and apply immediately, and those will be (I believe) helpful and appreciated by all.

5. Huddle daily

Daily huddles aren't new or different from things I've written about over the last several years.

They're my go-to tool for making sure people, and more importantly, projects aren't hiding in a mode that's not very productive.

If a project isn't talked about for a while, it's easy to assume you know its status, even if you're wrong. If a person hasn't checked in for a few days, it's easy to assume they're busy working on a task that isn't reality.

So I have daily huddles – one with front end developers, one with back-end engineers, and another with European staff (at a different time because of their time zone).

It helps to check in and see what's been completed each day.

6. Don't allow phantom allocations

It happens in every company. It's a dynamic I've seen in every professional services team or group that I've been a part of (in product companies they're the implementation team).

It's the allocation of resources for a given week before you've ascertained than the client actually has delivered everything they need to.

Everyone wants the same developers. Everyone wants to book time with a senior resource. So they book the time. They allocate part of his or her week to their project. Only to find out that the client didn't have their content ready.

Shock, right?

Only, in doing this, a phantom allocation occurred. A resource that could have been on a project wasn't allocated to it because of the other expected project – even if it didn't happen.

So we've killed all phantom allocations. And it's helped us considerably.

it's also helped us explain to clients that we need everything prepped if we're going to allocate resources.

7. Leverage Partnerships

If you've been watching some of our recent announcements you'll note that one of my first efforts was to work on a relationship with iThemes so that we could help them think about their products for our enterprise clients.

We just also announced partnerships with Zeek for mobile products and with Web Savvy Marketing for SEO services for our enterprise clients.

It's a model that suggests a single company doesn't have to do everything. Our clients want a single company to be on the hook for large projects, but that doesn't mean we can't partner with others to bring them in as sub-contractors.

It lets us stay focused on what we're working on, while giving other companies a chance to thrive in the ecosystem we know well.

 8. Create a strategy for giving back

The truth is that this one has been the easiest because our CEO, Karim Marucchi, already had some plans in place. He's been working to help spin up meetups in parts of Europe where we have teams. It's a part of our strategy, no doubt.

He's also sponsored WordCamps across the United States and in Romania. Another component.

But, and this will be it's own post, part of the task he assigned me was to figure out how to think about giving back from our engineering staff – in a way that challenges them, grows them, and gives back to our WordPress community.

Crowd Favorite has had a history of contributing to core – but in recent versions we've not been very focused there. Our efforts have been in other areas (as I mentioned above).

But my recent work has been to help us focus on automated testing and particularly acceptance testing so that we can leverage it for our own customers while also giving back to the community as a whole.

So soon you'll hear more about our work with Scrutinizer and Codeception –  both of which I think will be very helpful for our clients and our community alike.

We have a great team

None of this has been easy. None of it has been perfectly executed or smooth.

But it's like working out a gym (so I hear), you feel pain but it's only a sign that you're getting stronger.

The changes haven't generated cheers, but people haven't escorted me out of the building. And slowly we're seeing the fruit of these changes. Changes that I know will bring out the results everyone wants.

What has made all of it worth it is the team we have. They're smart, funny, and it amazes me that some of these folks can crack a joke when they're living in 23 degree weather (Denver, Michigan, etc).

It's been a very full 8 weeks, but I'm looking forward to the next 8 months, and the many months after that…