{32} Dev Agency, Personal Strengths & Collaboration
{32} Dev Agency, Personal Strengths & Collaboration
Featuring Cory House, Nick Bryant, Dini Mehta, Hakan Deryal, and Alfred Nerstu
Subsribe to The Daily Subset and develop the skills needed to build a strong product led growth startup.
Product: Development Agency
Cory House
I believe the idea has potential. Here are a few challenges I see and potential solutions:
1) Developer buy-in – Many developers have become accustomed to fighting for high-resolution specs. This is often the result of people being held accountable for unforeseen challenges that arise after a project is poorly planned.
Manager: How long will it take to build X?
Developer: I don’t know. Maybe a week or two…
Manager: Great. Let’s get started. I expect it to be done in a week.
A week later, the developer is scrambling to get the project to the finish line. So many layers of complexity make it obvious that it should have been a 4-week project. None of those considerations were discussed ahead of time. So now the developer has to work twice as hard to produce shitty results that nobody is happy with.
The next project has a developer thinking “I don’t want to do that again. I’ll be much more conservative in my estimate, and I’ll make sure we properly spec it out”.
The above scenario is not healthy. We should not incentivize people to sandbag and guard their time. We should incentivize people to take risks and explore opportunities to deliver as much value as possible. Because of that, I like the “no docs” approach. A great developer unencumbered by a heavy process has the potential to produce significantly more in a fraction of the time.
To make this work, we need to undo some negative programming. Take away the stick and focus on the carrot. Developer comp should be proportionate to the value they create. Treat developers as fractional entrepreneurs.
2) The system should be less reactive – I know many people want to make customers the project managers. It’s tempting to just do what customers ask for in real time, especially as an agency. But being reactive has pros and cons. It’s nice to deliver value quickly, but with no prioritization, it’s hard for developers to maximize their time investment.
Instead of taking a real-time approach, I’d add a 1-day buffer. There should be a system of feedback collection that does not interrupt anything in progress. Just allow all the feedback to pipe up for the day. The next morning, the team should get together and evaluate yesterday’s feedback and plan their day. Once everyone has decided their focus for the day, there should be as few interruptions as possible.
Communication: Async
Nick Bryant
I’ve always been a fan of async communication. It’s opt-in. You can find ways to fit it into your workflow without blocking large chunks of your day. You aren’t obligated to participate in conversations if you don’t add value. There are so many benefits.
In spite of all the advantages, we can’t seem to give up our synchronous communication addiction. I wouldn’t be surprised if the average tech worker spends at least 3 hours in meetings every day.
Maybe the problem stems from our need to verbally communicate face-to-face. We have the tools to communicate face-to-face async. You can record and post short video clips in Slack. But that functionality doesn’t seem to get a lot of usage, at least in my experience.
I don’t know the answer, but I hope we find more meaningful ways to get more out of our sync and async chats. Good luck to Nick on his quest. 🍻
Productivity: Focus on your Strengths
Dini Mehta
It’s a good idea to focus on your core strengths. Strengthening your weaknesses makes you a better generalist, but it’s also a losing battle. You can’t possibly be good at everything. So spend most of your time doing what you are good at and be thoughtful about expanding your skillset.
The outsourcing your weaknesses part is a whole discussion in itself. I believe it is better to collaborate than to delegate. While most people believe in delegating, there is a major flaw in that thinking. How can you effectively delegate if you aren’t a subject matter expert? If it is your weakness, then you are less equipped to make decisions than the expert doing the execution.
In a collaborative environment, experts are able to contribute their strengths while trusting other experts to contribute in areas where they are weak. Creating a collaborative environment is not easy. In a lot of ways, it’s easier to just delegate. But the upside is higher.
Collaboration: Ownership
Hakan Deryal
This is a continuation of the discussion on productivity. 👆
Teaming up with people who are strong in areas you are weak is generally a good idea. One potential red flag here is the use of the word “ownership”. I don’t believe hard boundaries over domains involving absolute authority is a healthy setup. In other words, you shouldn’t say, “I decide everything tech related, and you decide everything marketing related”.
It’s better to say, “I’ll take the lead on tech, and you take the lead on marketing”. The difference might sound insignificant, but it’s meaningful. It means that you, as a technologist, aren’t excluded from marketing decisions. And marketers aren’t excluded from tech decisions. Input from both sides should not only be invited but encouraged. It builds trust and helps the team arrive at better overall solutions.
Domain: Motivation
Alfred Nerstu
Congrats on the name and good luck Alfred! 🎉
It’s hard to put a price on a domain. But one major reason to pony up the cash for a name is motivation. Paying $10k for a name that you feel personally connected to might inspire you to work 10-20% harder than a name you are less excited about. Extrapolate that effort over a year, and suddenly $10k seems like a hell of an investment.