Up Up And Artisan

I alluded in my last post there was one more reason. Startups move fast, and this reason was no exception. It came swiftly, and I reacted. I followed my gut.

Reason number five: an amazing opportunity

I’m joining the engineering ranks at Artisan Mobile. I’m going to dent things with a team of experienced entrepreneurs and builders who get it. They get launching products. They get growing companies. They get nurturing communities. We’re going to change the mobile landscape. We’re going to change our city’s startup landscape. I truly believe this.

My path - the one composed of milestones I hope to hit, endpoints I like to reach, and people I hope to be with me over the course of my career - has led me here. I intend to continue following it and leave my mark.

Reasons

Yesterday I resigned from konciergeMD. It was not a decision I took lightly. I obsessed over it, I lost sleep over it, I talked about it until I turned blue. I stared at it and it stared back. I respect my gut. I don’t follow it blindly but when it speaks, I take a seat and listen. I’m passionate about what I do, and I’m my best when I’m drowning with where I am and what I am doing; insane yes, but why kid myself, that’s how I’m wired. Over the last month or two, I was not drowning, and I grew concerned with answers to questions I often ask myself. 

There were four reasons why I felt it was time for me to move on. Well, five, if you include the amazing opportunity on the other end.

Reason number one: questioning ownership

konciergeMD is pre-A round, and, when you’re securing that round is hopefully not far off in the distance, it’s natural to start to think about where you fit in, what areas of the product (or products when you’re a multi-product company) you want to own, and what pieces of the company you want to take hold of. Perhaps more importantly, there should be little to no hesitation in answering these questions, especially after pouring nearly a year’s worth of your life into building it all. I hesitated. Worse, I had trouble answering.

Reason number two: questioning personal interest

It’s an awesome experience (and frankly smart) to build something that is ultimately intended for you. When the builder is near the target user, you’re in a unique position to ask yourself, “Would I pay for this?” At the end of every sprint I’d ceremoniously ask myself this question. A fair number of sprints ago, my answer changed from “hells yes” to “I don’t know”. Let me make something very clear, this is not a reflection of the product, it’s a great product, and I most definitely believe people will pay for it. If I didn’t, if the team didn’t, if investors didn’t, the company would not continue to exist. For me personally though, the answer at this moment was “I don’t know”. And as a maker, if you start to question what you’re building, as the creator or consumer, it’s a predicament, because it’s a mentality that eventually bleeds into your work. With that realization, I fought for the consumer in an application built for a two-sided market. I tried to influence the direction of the product, to alter its course to a path that would influence my answer. That’s not how it’s done. A product is a living, breathing thing, it has a direction, you can alter its course, influence it, but unless there’s the entire product team is behind a pivot, even the smallest of pivots, it ends up more detrimental. That’s not being the best builder or team member I can possibly be.

Reason number three: questioning cultural alignment

Builders come in all shapes and sizes, molded by a vast array of experiences. In this particular instance, I mean builders in the broadest of terms. Not developers, not designers, but anyone who’s in the business of building a product. In my experience, builders in startups often have a unique piece of code in their DNA. It’s most definitely not required code, but it’s common. And you don’t normally find this code in “big company” people. The startup code which is a part of my DNA manifests itself in me in lots of ways: how I build, how I act, but probably most important, it influences the core of my beliefs.

I believe a product team should have just enough process, just enough code, just enough friction, to move at the fastest rate possible yielding a result that is perfect for a given time and place. I also believe a product team should have little to no walls. Communication should be such a natural act that it happens without any effort, between anyone on a team who has a stake in the product, without plan or pre-meditation. Exercising these beliefs was challenging in light of differing philosophical opinions.

Reason number four: far from the epicenter

Working outside the city, I’ve been feeling disconnected from the startup renaissance happening within it. There’s a vast amount of talent - engineers, designers and entrepreneurs - and I try to surface them through events like Startup Weekend. Working (physically) far from those communities and having a different opinion of those circles philosophically than others in the company, I found myself unable to contribute as much as I’d like. Something is happening in town: venture capitalists relocating from the suburbs; angel investors choosing to focus locally; companies setting up shop in hubs such as N3rd street; engineers moving here for opportunities. I want to be a part of it, I want to help it take root and blossom; it will carry me for the rest of my career, or at the very least, the next stage of it.

I’ve put a lot of thought into these reasons. I’ve studied these questions from various angles, through the eyes of my peers, the individuals steering the next wave of companies in this city. I’ve talked with people I care deeply about, who inspire me with what they do on a daily basis, builders of all shapes and sizes. For all these reasons, and yes, for an amazing opportunity on the other end, I chose to resign. And while I recognize there is impact to the current team, having a builder that’s not drunk on kool-aid is way more detrimental in a startup.

My Recipe

At this exact moment, I think this is my personal recipe for happiness, it will change, but today, this is it:

  • Change, often. (see, I told you this recipe would have a short shelf life)
  • Find a partner in crime, the sooner the better.
  • Use envy for motivation. Or revenge, but mostly motivation.
  • Be nice, especially when every fiber of you wants to be mean.
  • Make promises; try your absolute very best to keep them.
  • Wherever you’re going, show up, that’s the most important part.
  • Surround yourself with people who are better than you.
  • During moments of bliss, take a mental snapshot; revisit those snapshots often.
  • Daydream. It will result in moments of glee and anguish; both emotions mold you.
  • Whatever you do, be good at it; continue to raise the bar on what you define as good.
  • Stay up late or wake up early, your choice, but secure time for yourself.
  • Listen to music. The more your tastes are like mine, the better.
  • Play music. Air instruments count.
  • Be a teeny bit absurd, it’s more fun that way.

Cross Cut Of An Engineering Blob

Building a product is hard work. Building a product that constantly changes course due to environmental factors is incredibly hard work. It demands an eclectic crew of characters that when combined, form an amorphous blob. A blob? Yes, a blob. A squishy gel able to squeeze into small containers. An elastic substance able to cover the broadest of areas. An odd material that while gelatinous can support heavy loads.

Here’s a cross cut of the blob I’m currently a part of. This team will change, teams always do - members leave, focus changes, gaps emerge - but today, this is my team, and we’re doing a fantastic job of navigating shifting waters.

We’re sliced four ways: back end, front end, operations, and design; novel, I know. Back end consists of feature development (where front end interactions are at a minimum) and infrastructure. Front end focuses on client side applications with heavy interactivity, site styling, and mobile. Operations is responsible for keeping the machine running. Last but far from least, design. These areas make up our four walls.

Occupying the space within the walls are 8 individuals: 6 engineers and 2 designers. Our engineering team is comprised of three back end engineers, two front end engineers, and a hybrid (me). As far as how this army of eight spread themselves out across these areas fluctuates, depending on the need of a sprint. I’m going to focus on our engineering team here.

Back end engineering occupies back end and operations. Our stack - Java/Scala, Play Framework, Akka, AWS (VPC, EC2, ELB, RDS, S3, Data Pipeline) - has the necessary knobs and levers enabling us to scale when the time comes. Deployment is automated, enough for where we currently stand anyways; you can always automate more. All in all, we have some runway as far as operations goes at this stage in our product’s life, so the focus of our back end team remains predominantly on new feature development.

Front end engineering is more volatile in terms of shifting focus. Our front end engineering team owns client side applications, the lion share of rich interactions, styling, and (HTML5) mobile. I know you’re saying that responsibility set is too sparse, and frankly, you’re probably right. But we’re a startup and we’re resource constrained, we find a way to get by.

Two dedicated front end engineers focus on these areas, running at mach speed. Early on, we did pay an upfront cost to lay down the front end foundation that we now rely on. During those periods of development, we were not as productive in terms of feature releases. The investment has paid off since. Our stack - Backbone, jQuery, HTML5 for mobile, LESS for styling assets - is mature enough that, despite the disparate nature of the tasks this team tackles, the team runs efficiently amidst shifting gears.

I swing between the back and front end engineering teams, depending on the demands and needs of a sprint. If a sprint has a large story set focused on mobile, I’m on front end. If a sprint is comprised a lot of rich client side functionality, I’m on front end. If a sprint has a substantial amount of new features, requiring API work or new models, I’m on back end.

Given the age of our product and the pace we’re running, this makeup (a diverse group of individuals with areas of expertise plus the ability to swing between areas of the application) is working fairly well. Iteration will continue and with that so will the dynamics of this blob.

Back From [Insert Something Here]

We all disappear on occasion. We fall off the grid. We get buried in life. Some apologize for these absences, or worse, make excuses. I don’t. I feel they serve a purpose. They offer a chance to reflect, to step back and evaluate one’s interests and passions.

There’s a reason why my last post was 8 months ago and why it’s the only post I chose to carry over from previous blogs. These months have been some of the most dramatic of my professional life; I’ve been dented, in a very good way. When I pull my head up and look at my view today, there’s clarity and numerous relationships that did not exist before. When I take a moment and press pause, I feel new passions emerging and dormant ones re-awakening.

This is me returning from my absence. I’m not going to apologize. I’m not going to make excuses. I’m not going to promise I’ll post weekly. I am going to promise to get back to sharing. I am going to talk about the highs and lows of startup life and the immense amount of juggling skills it requires. I am going to discuss the challenges and lessons I’ve learned while trying to launch products. I am going to share the ongoing experience of helping shape the Philadelphia startup ecosystem, an ecosystem that is rapidly maturing, coming into its own, and one that I plan on being intimately a part of.

I’m happy to be back, in my own skin, and I have to say, it fits better than ever.