Skip to content

Business - 3. page

Are you working on the business or in the business?

Dog in a suitAs a business owner, it’s important to realize that the engine of the business (the people and processes that allow you to make the product or service, whatever that is) is as important, if not more so, than the product of the business. This changes over time, of course. When you are just starting out, the product needs to be made, otherwise you won’t have anything to sell. But over time, the other aspect, the business structure, will come to the fore. This is because as a business scales, you need to be able to recruit new talent, market your product, and spread knowledge throughout your company.

I was reminded of these facts by this post, “My Biggest Regret”, from Marty Haught, of Haught Codeworks. He’s kind of a big deal in the Ruby community, but reveals that he was a bit … lazy when it came to business development. From the post:

Apparently, I’m not the only one with this impression. You commonly hear that business owners need to work on the business, not in the business. I loved building software so much that I just wanted to stick with that.

That’s the perennial issue with building a business to give you freedom. Be aware that the bigger the business you build (the more successful) the more you’ll be taken away from building the product and the more you’ll be pushed toward building the business. (There are exceptions, but they require a certain scale. I’m aware of a couple of technical founders who stepped away from business management and focused on development/new initiatives, but that’s rare enough that it is worth commenting on and it also requires a team of about double digit size and margins to allow that to happen.)

The business principles of the solo consultant apply to big companies too. Doing the work is only part of building a business. Ignore that fact at your peril.

Business | moore | | Leave a comment

Podcast Pick: A16z

I have been enjoying the A16z podcast for the last couple of years. It’s regular, dense content on a wildly varying set of technical subjects. I love hearing Benedict Evans talk about, well, anything–I find him quite insightful. But the podcast is not so dense I can’t listen to it on 1.4x speed.

I tend to listen to the more software specific episodes on APIs and on B2B2C business models (which seems to have been deleted). But every so often it’s nice to be jarred out of my world and listen to an episode about product or space or investing.

You can listen to past episodes here and get the RSS feed here.

 

Business Podcast | moore | | Leave a comment

A follow up to “Deeply problematic but practical advice”

I linked to the first article Charity wrote, and wanted to link to her follow on piece/”post mortem”. (In technical terms, a post mortem is an examination of a problem or system failure in hopes of avoiding the situation in the future.) From the post, she encountered some very harsh words from the Internet:

I have never received textual scrutiny of this type before, where every single word was turned over and macerated and peered at for evidence of traitorous views. It sucks.

Lots of good stuff there about the reactions to her original post, her takeaways and how she would do some things differently next time. Worth the read.

Business Technology and Society | moore | | Leave a comment

What is your BATNA?

When you are negotiating, you always want to be thinking about your Best Alternative to a Negotiated Agreement (BATNA). This applies in any negotiation, whether business, personal or even with yourself. When you have a better BATNA, you have more negotiating leverage and are more likely to get what you want out of it.

This is why when I was a contractor, I always had more than one client. Even if I was working with a good client who paid well, on time and was fun to work, I had more freedom if I had another client. Things might go south at the first client and I wouldn’t be out on the street. It’s also why I would always start looking for a contract 6-8 weeks before my current contract was finishing.

It’s why you should always get competing job offers. If you have a job offer and your best alternative is to keep job hunting, that’s not appealing. If, instead, you are choosing between two job offers, you are in a much better position. (No duh!)

It is also why it’s always easier to get a job if you have a job. The BATNA of declining a job offer when you have employment is, well, you remain your current position. Your current job may not be all that awesome (which is why you are looking) but for most folks being employed is a better alternative than being unemployed.

How can you use the concept of BATNA to improve your life?

First, be aware of the concept. Start to look at decisions in your life and think about the BATNA. Even small decisions, like ‘should I get coffee or nothing’? Or ‘what happens if I ask my wife to take out the garbage’? Or ‘should I ask for a raise’? In all of these cases, you can expect some kind of negotiation, and you can think about what the alternative is if that negotiation fails.

Second, take actions to improve your alternatives. If you are unemployed and want more leverage in the job hunt, start consulting. If your wife won’t take out the trash, can you improve your BATNA by making it easier to take out the trash yourself (maybe move the trash can into the garage)? Or building some kind of trash chute?

The concept of a BATNA is key to getting the most out of any negotiation. If you have good alternatives, you have more leverage to leave the negotiation, and if you don’t, you will need the negotiation to complete successfully.

More about BATNAs and salary negotiation here.

Business Contracting Basics Jobs Lifehack | moore | | Leave a comment

“I want it all and I want it now”

Do you want it all? Should you?

Jason Cole has some wise words on the various hires you can make to make your life easier as a technical founder.

There’s a myth in our industry that you can write code and manage people, and that every engineer should do both if they want to advance their career. While I know people who are good at both, they’re generally the rare kinds of people who can hold two opposing concepts in their minds at the same time. And they never get to straddle those two areas for long; they either become a senior people leader or a senior technologist.

This is the old CTO vs VP of Engineering split.

So, as you grow in a company as a technical founder (or even an early engineer) you need to make a decision. And when you are hiring, instead of searching for someone who can wear all the hats that you used to, find someone who can take two or three of your hats and put them on. It’s the beginning of the transition from generalists to specialists.

Business | moore | | Leave a comment

Product Roadmapping For Team Alignment

One of the issues with a startup is that you have so many opportunities and so little time. This is overwhelming, and can lead you to pursue opportunities that fall in your lap, or that your squeaky wheel customers offer up, rather than thinking strategically about where you want to go and how best to get there. This is heightened by the ‘everything is on fire’ feeling that arises occasionally.

At The Food Corridor, we just spent two days roadmapping (we being The Food Corridor team and the OTL Ventures team). Normally I’m not a fan of meetings. I find they often are synchronous status information transfer that could be better handled via email or slack. As an aside, here is a great post on running a meeting.

But this roadmapping meeting was great. The team was all in the same room and spent the first day brainstorming opportunities (with no limits on the feasibility of the suggestions, but some guardrails around focus). The second day we ranked all opportunities according to positive impact and effort required (both in a number of dimensions). As you can imagine, these were two long days. However, the outcome is a list of high impact, low effort opportunities.

However, I feel the real value isn’t in the list, which will be so long that it won’t be accomplished in the next two years, let alone by the next roadmapping session is scheduled. There were two main items that came out that I found really valuable.

First, that were discussions with all relevant parties about real issues in the business. Sometimes we get so busy delivering that we don’t pop our heads up and see the bigger picture. As all imperfect products do, The Food Corridor causing some pain for our customers. (If you work on an imperfect product, please let me know as I’d love to see one.) These pain points were front and center during the discussion, and we had people from multiple different functional areas opine on the problem and possible solutions.

There was also a ton of value in creating shared alignment. As I watch this business be built I am astonished at how much time and effort needs to be spent making sure everyone is pulling in the same direction. When I ran a business on my own (as a solo consultant) or when I am an employee, the focus is usually on what I’m doing “in the business”–the day to day execution of tasks to provide the services the company sells. As a co-founder, I’m seeing how important it is to get everyone agreeing on the highest value opportunities–highest value for the business, not necessarily the most exciting or highest value for each individual. This alignment needs to happen with incentives, meetings and communication. The just completed roadmapping session felt like it really achieved that shared alignment.

By the way, if you are a software product company in the northern front range and feel like you could benefit from more team alignment, I’d highly recommend contacting the folks at OTL and pursuing this. Not affiliated, just a happy customer.

Business The Food Corridor | moore | | Leave a comment

Metabase: An Easy Query Builder For Your RDBMS

If you have a relational database as the primary datastore for your application, and you want to easily allow non technical folks to build reports against data in that database, I highly recommend evaluating metabase. This open source query builder is dead simple to install (takes about one minute on a free heroku dyno). You can create individual users, and they all get access to an easy to use interface so they can look at data in your tables. All the nomenclature is non technical, nary a select, group by or from clause to be seen. It’s written in java, but you don’t have to know java to run it.

We haven’t used this for long, so I can’t talk much about the warts, but I was referred to this by someone else who had great success in using it in their organization. The only downside that I’ve seen so far is that joins are not supported, so you end up having to create views if your database is normalized. More on that decision.

BPA Business Java Useful Tools | moore |

When do you earn your pay?

I was driving today and saw a bus driving in the snow. I’ve never driven a bus, but I imagine that snowy days are some of the most difficult. The roads are bad. People are crabbier. Accidents happen. You are still on the hook for making the schedule. I’m no bus driver, but I bet when the driving is easy, as in the summer during off peak times, the job is easier.

However, when things get hard, that’s when you earn your pay. Since software development is such a sprawling occupation, it’s hard to generalize about the most difficult moments, but I can mention some of mine:

  • When I face a problem that you’ve never faced before and have no idea how to tackle it (like setting up recurring bookings over daylight savings time changes).
  • When I ship a bug that costs your customers money and I have to analyze how much money was lost and a game plan to fix the bug and get them their money. Then I need to contact the customers to apologize as well as let them know what the plan is.
  • When I realize I’ve chosen the wrong implementation for a component.
  • When I realize I’ve made an architectural decision which made sense in the moment but will have maintenance and performance costs down the line.
  • When the system crashes and I know the reason, but I haven’t figured out a way to replicate it or to fix the issue.
  • When a system is slow and I am unsure where to start looking.
  • When someone on my team isn’t working out and I need to let them go.
  • When I watch a user navigate around your system and totally miss features that will make their lives much easier.
  • When I join a new project/company/team and walk into an existing system of software and personalities about which I have very little clue. And yet I want to be effective and move things forward, but need to be patient.
  • When I argue with someone about the best way forward, and then my path isn’t chosen, and I have to support the plan that was chosen.
  • When I argue with someone about the best way forward, and then my path is chosen, and I have to work with people who disagreed and may not fully support the new plan.
  • When I am at the end of a project and I just want the damn thing done, and yet I have to maintain the same level of attention to detail that I had at the beginning when the idea was all new fresh and exciting.

You don’t earn your pay for the easy stuff. It’s when the going gets tough that you really earn your pay.

Business Jobs | moore |

Building a Bridge as Your Clients Walk Across It

There was an interesting article posted to hacker news about the nuts and bolts of a SaaS product that you might not expect (article, discussion).  I commented based on my experience that the early days of a SaaS product are like building a bridge while your clients are walking across it.  You want the bridge to be far enough ahead of your clients that they won’t fall off it.  But, not so far that if you or they want to go a different direction you’ve wasted time and materials building a useless walkway section.

So, don’t build features your customers aren’t going to use. But do build features they are going to need. How do you know what the difference is?

  • you can ask them.  This is the only way to start unless you are a target user of your SaaS product (in which case, ask yourself).  Depending on the technical sophistication of your users, you may or may not get good requirements, but there’s no better way to understand their pain.  They will speak very confidently about their pain, however they will also try to give you suggested solutions.  Don’t take those as gospel, as they may not have thought through the ramifications of said solutions.  Find them by looking where they congregate online (facebook groups, forums, reddit).  Targeted email may be OK if you have a relationship.
  • you can build a placeholder.  This is a great way to see if folks want the feature, if you have some folks using your app.  We built a placeholder for document management: “email us and we’ll upload your documents”.  After a few emails, we knew it would be worth it to build out some way for folks to self serve.
  • you can build a MVF (minimum viable feature).  A feature does not need to spring from your mind fully tested, polished and automated.  Sprinkle in manual steps, use emails to people instead of automation, or release only a subset of a feature.  The goal here is again to see usage before you fully develop it.  Another benefit is that the MVF may be all that is needed.
  • you can wait until clients ask for it.  The value of this depends on when they need what they ask for.  If they need it when they ask for it, then it’s just another data point (“thanks for the request.  We’ve noted it in our roadmap”).  If they need it a week or a month after they ask for it, then you can actually build it for them.

It actually can be quite helpful to checkpoint feature usage every so often.  I’ve seen this done two different ways, though I’m sure there are more.  The first is to look at the data and see what features clients are using.  This is nice because it just takes developer time, digging through your OLTP database.  Make sure you write down the results and the queries.  However, this won’t work until you have some users who’ve been using your system for some period of time.  The second is to schedule user interviews and watch your clients or prospects use your system.  This is time intensive, but can lead to many many insights and gives you definite user empathy.

Now, this type of development doesn’t free you from having a strategy. You need to pop your head up every three months or so and revisit the strategy and see if your business is working toward it. But if you are a completionist than early stage SaaS is not for you.

Business Web Applications | moore | | Leave a comment

Switching Scales

Developers need the ability to switch scales. I don’t know if this is crucial for any other profession (maybe a general contractor building a home?). For developers the ability to zoom in and focus on a specific problem for a few hours, and then zoom out and focus on the bigger picture, whether that is project management and reporting, or system architecture, is crucial.

The way I do it is to compartmentalize rigorously. This means that when I am focused on a bug, I’m focused on the bug. Sometimes I’ll timebox such investigation so I don’t get wrapped around the axle of the problem. If I encounter other issues, I file them off in the issue tracker (you do have an issue tracker, don’t you)?

If, instead, I’m focusing on the big picture, paradoxically it can be harder to focus. I think best when writing, so I’ll start out with a document outlining the issue. This has the added benefit of allowing me to easily collaborate (google docs FTW), refind the problem definition and solution, and revisit it over time. Other folks work better with other artifacts (app click throughs, diagrams) but the information density and flexibility of written communication work best for me. However, either way I need to set aside some time to focus on the question at hand.

Once you compartmentalize successfully, you can start to have the each scale inform decisions made at the other. Bugs that may feel urgent to fix can be deferred because that system is not accessed often, or will be rewritten soon. System diagrams may be reworked because you know that sub components belong together (or don’t). You may know where the “dark, scary” areas of the application are and make time to rework them. There may be patterns of code or services worth extraction.

One of the hardest parts of management, from personal experience and discussions with others, is letting go of the details. As an engineering manager, you should absolutely let go of critical path implementation items–you shouldn’t be working on the hardest problem or any key components. Depending on the size and needs of your team, your focus may be on recruiting, providing political cover or knocking down impediments to team goals. But I think you need to have a touchpoint at the lowest level of your application. Whether that is achieved through non blocking code reviews, fixing non critical bugs, or knocking out a customer support request, zooming in to the implementation level will inform your worldview. Just don’t let it be too large a focus; definitely don’t let it block your team.

If the idea of letting go of product implementation doesn’t appeal to you, you may want to dive in to management more. There are plenty of details and challenges to management (read High Output Management for a great intro). In fact, there are similarities between building a successful piece of software and building a team that builds a successful piece of software. People aren’t code though–imagine if when you ran a function you got a slightly different result based on how the function felt, how its home life was, what previous work the function had done, etc, and you’ll have some idea of the complexity of management.

If you’ve tried management and it doesn’t work for you, you can remain an individual contributor. Realize this will have an impact on your compensation (in most orgs) and your leverage (link) to effect change.

But it may be worth it to remain a builder.

Business Programming | moore | | Leave a comment