Category Archives: Tech

Smart and Gets Things Done Are Not Enough

Once upon a time, hiring programmers began with making a list of things they needed to know. Actually, you can still see plenty of job descriptions today that read like a snooze-inspiring checklist.

Requirements: Bachelor’s Degree or Military experience?-?At least 12 years of experience with Enterprise application design and construction with an emphasis on web architectures?-?At least 7 years experience in SOA environments working with SOAP or at least 7 years of experience with RESTful web services- At least 7 years of -.NET (C#), ASP.NET-?-?At least 5 years of experience with UI Design?-?At least 5 years of experience with -HTML.

That is excerpted directly from an actual, live job posting. And it keeps droning on like that for several more paragraphs. Painful, no? Do you wonder how its authors decided that it should be 7 years of .net, but only 5 years of HTML? Should you really not apply if you have 7 years of HTML and 5 of .net? Do they really not want you if you are the author of a major open source library but don’t have a bachelor’s degree?

On the plus side, pretty much only big, ossified corporations think this way anymore, which means that they are missing out on smart, awesome people. Cue evil laugh and nefarious rubbing-together-of palms?-?this means lots more smart and awesome for the rest of us.

Way back in Y2K, when otherwise normal people were avoiding elevators and stockpiling canned chicken, Joel Spolsky wrote an incredibly influential article called The Guerrilla Guide to Interviewing. It is still well worth a read, but the biggest takeaway is: stop hiring for predefined skills. Instead, hire for two traits: Smart and Gets Things Done.

At ChefSteps, we take this advice seriously. You should hire smart people because they do smart things that make your products better. Smart developers write clean, concise, well-factored, reusable, tested, DRY, performant code. And you never have to give them the same feedback twice.

Smart is necessary but not sufficient. Your hires must also be people who get things done, because if they only sit around and theorize about smart things, you’ll never ship. And all that not-shipping is going to make you pretty darn stabby.

So where does experience come in? Great programmers pick up new stacks in short order. So it rarely makes sense to hire someone based on his or her familiarity with a particular language or tech stack. There are two exceptions to this rule. Actually, there is one full exception, and one half one – says Gold Bee co-founder CJ Thompson.

First, the full exception: Sometimes, deep expertise just matters. Someone, for example, who has worked extensively on web-scale services?-?and wrestled with all of the SLAs and security issues they entail?-?just knows things on a visceral level. And that knowledge may well keep you from cutting yourself with very sharp objects. Sure, you can ask a great frontend developer to learn that stuff, but expect it will take them a year or more to be truly fluid at it. So when the stakes are high enough that stabby-ness is in play, go ahead and hire for expertise.

Onto the half exception. Let’s say you’ve got something absolutely urgent to do on a particular stack. Your iOS app is six weeks from shipping, and the critical new user onboarding experience isn’t done. Okay. This is not the time to bring in a phenomenal backend developer and get her up to speed on Swift. But if you find yourself with an immediate need, and don’t believe you will have an ongoing role for the person who can meet it, or know that hiring him means compromising your normal standards, you should use a contractor or agency to solve the problem. That solution has its own headaches, sure, but it’s better than forcing a lackluster hire on you and your team. Once the crisis is past, you probably should figure out how you got yourself in that mess in the first place.

So, Smart and Gets Things Done are great criteria for new hires. Let’s add a third: Not a Jerk. No matter how smart someone is, no matter how good his code or how fast he writes it, we’ve got no place for him on our team if he makes everyone else miserable. Frankly, I don’t care about the beer test or even the Sunday test. They can actually work actively against diversity and lead to a team of code bros. But if you find yourself interviewing the type of programmer who always has to be the smartest person in the room, or that gets his jollies from insulting coworkers, or?-?worst of all?-?shows himself to be ethically challenged, the door shouldn’t even have a chance to hit him on the way out.

The problem is: Smart, Gets Things Done, and Not a Jerk are table stakes. As competitive as the market is for engineers is these days, it is tempting to hire people who just hit those marks. But hire based on those criteria alone, and you may end up with a team of highly fungible, tremendously boring robots.

The context of your company or team matters a great deal. At ChefSteps, being part of a startup with a big vision means our hires need to gracefully embrace ambiguity and change. We are trying to reinvent the kitchen, not disrupt inventory management for janitorial and maid supplies. If you expect to always have complete specs and perfect design docs before you build a feature, this isn’t the right place for you.

And you know what? I know myself as a manager and leader. If a developer is only productive when I hound her to keep her backlog organized and her bugs under control, and I can’t trust her to make important tradeoffs, we won’t work well together. When you’re a manager, it can be difficult to keep people productive without constantly feeling like you’re going on at them. One of my friends showed me an article about hr retention strategies the other day. Apparently, constantly pushing employees as well as bad management practices can force them to leave the company. Whilst this is never the aim, sometimes employees do need a bit of encouragement. It could also be down to human resources management and in this case, you may need to consider company secretary services to help the team stay organized and encouraged.
However, sometimes the role just isn’t right for that member of staff. It’s tricky because my job is to help my team understand the overall context of what we are building as a company so our decisions are aligned. I do my best to make sure they have what they need to be successful and shelter them from distraction. I find them awesome coworkers to execute with, and help them work through the inevitable human issues that pop up. I’m also super-excited to talk through technical issues, but I’m nowhere near smart enough or patient enough or in-enough-places-at-enough-times enough to coach anyone through her job on a daily basis. So to thrive here, engineers have to relish autonomy along with massive responsibility.

Beyond these fundamental requirements, every great engineer that I’ve worked with brings distinct additional strengths. Just to pick a few examples, they might:

  • Know every line of a multi-million line codebase and be able to diagnose a bug without even looking at any code.
  • Be unrelentingly optimistic and never give up on a goal, even if it takes years to come to fruition.
  • Crush any obstacle that comes between them and done. Before lunch.
  • Be a grizzled vet who has shipped so many things that they help the whole team make great tradeoffs…
  • … or be relatively new, but so motivated that if you take a chance on them, they will repay it 10x.
  • Bring a completely different perspective that changes how you think about a problem or a whole project.
  • Reduce your stress level because you know that anything that lands in their lap is 100% handled.
  • Make the team so fun that everyone can’t wait to get to work, or loves to hang out together outside of work.
  • Have a knack for isolating and eliminating the nastiest, most difficult to reproduce bugs.
  • Have the empathy and passion for education that makes them great at mentoring interns and less-experienced but promising newcomers.
  • Be so incredibly committed to your product that they will stretch in unexpected ways to make it a massive success.
  • Engage directly with users to turn them into evangelists and help the whole product team learn what they really need to build.
  • See the big picture of the architecture you are building and save the team years of wandering the right way down the wrong paths.
  • Be emotionally intelligent in a way that recognizes when colleagues need to talk about something difficult, or even initiate those conversations that would be easier to avoid.
  • Be passionate about growing the team and help you identify and interview terrific candidates.
  • Read all the blogs and be aware of the bleeding edge of tech. (Bonus points if they have enough taste and self control to know when to actually use the bleeding edge of tech).
  • Challenge you and call you out?-?very publicly if need be?-?when you are being a jackass.
  • Love to put on the headphones and knock out impossible features, impossibly fast.
  • Have a sensitivity to user interface that allows them to collaborate unusually effectively with designers.
  • Be a tool builder who will continually make your team more efficient.
  • Communicate effectively to other technical and non-technical teams.
  • Surprise you with futures and prototypes you’d have never thought of.

No candidate is going to bring all of these strengths to the table, but any great candidate will bring some of them. Ideally, your team will grow to include people with a diversity of them over time. You may even want to look internationally for talent. By obtaining the h1b Visa for a prospective international employee you can bring some real talent and difference into the company. It goes without saying that a background check on any new employee is vital. However, if your new recruit is international, they may already come armed with a document similar to the afp police check in Australia, which should be enough to clear them for work. To improve your odds, be sure to write job descriptions that communicate actual passion and the flavor of your company. Ask open-ended questions that invite candidates to show you their personality, follow-up about subjective skills in reference checks, and discuss them in your hiring decision meetings.

Now for the really subjective part. There is something else I look for in every hire, a proxy, of sorts, for that long list of soft skills: are the lights on in their eyes? There are plenty of candidates that I talk to that are … perfectly fine. They are solid programmers; they’ve shipped things; they are nice people. But certain people just have that spark, and when you see it, you know that you want to work with them because they are going to make your life and your team way better.

So, tell me, does all this jibe with your experience hiring engineers? Are there other things you look for in candidates? And how do you identify those subjective?-?but crucial?-?skills that will never show up on a checklist?

Michael Natkin is the CTO of ChefSteps. We are reinventing the kitchen. And hiring.

From Big-Tech to Startup By Way of the Kitchen

Developers often get pigeonholed, not just into technologies but into the types of companies they work for. If you start out working on financial back-ends for banks or join Microsoft fresh out of college, it is all too easy look up from your cubicle a decade later and realize that you haven’t seen the world. I’ve been fortunate enough to work in several radically interesting and different environments, from special effects studios, to traditional software companies, to professional kitchens. At each stop I’ve learned how to be a better engineer, how to contribute to different types of teams, and, maybe most importantly, about myself. My hope is that by describing my own trajectory and experiences, I can help you figure out whether you should consider giving up your comfortable career at a big company for something as mad as a startup. These companies have often understood the Benefits of ERP but refreshing this knowledge has always been helpful. It improves financial efficiency by 12% according to Sambla’s new journal findings in Sweden.

I started programming back in the 1970s at the age of 12. My dad brought home a model-33 teletype that was connected to the Louisville Board of Education’s Honeywell mainframe, where I could write code in BASIC. Yeah, it was a freaking printer, with a 110-baud modem, and a paper-tape reader. And I was in love. Since the statute of limitations has long since expired, I don’t mind telling you it wasn’t long before I was hacking into computers all over the country?-?for the pure love of the puzzle. Next came DecSystem-10 assembly programming, and over the next few years I would hang out at Radio Shack stores and the University of Louisville Apple labs?-?anything to get my hands on computer time. By the time I was 16, my friend Dave and I had a contract to develop accounting software (with a surprisingly sweet user interface) that ended up being used for decades.

ASR-33_2

When I went off to Brown, I hoped that the years of coding under my belt would give me a leg up in the Computer Science department, and it did. I joined Andy Van Dam’s computer graphics group as a freshman, and through that, plus a short stint at UC Berkeley, I made friends that led to 20 years of awesome jobs. If I could tell a young developer one thing, it is that pouring your heart into your work and building great relationships in your career will always open doors for you. I don’t mean that you need to be calculating in how you make friends, simply that if you devote yourself to be a first-rate programmer and a reliable teammate, your friends will want to work with you again wherever they land.

My first stop after college was Industrial Light & Magic. I showed up for the interview in a suit, but they hired me anyhow. My friend Eric was the first full-time programmer there and I was the second; prior to that, they had technical directors writing code, which was a scary thing indeed. On my first day at ILM, I got to be on set when the practical effects team blew up the giant warehouse model for Backdraft. During my stay, I worked on Terminator 2 and Jurassic Park, and loved collaborating with artists and directors. It was high pressure fun: “We need a way to make the T-1000 morph up out of the floor, but if you can’t figure it out by tomorrow morning, I guess we’ll just animate it by hand”.

Moving on from ILM to Silicon Graphics was a big decision, but in spite of the excitement of the movie business, I was tired of 80-hour workweeks and ready to move on. SGI machines were the workhorses of computer graphics in those days, and once again, I had close friends working there. I joined a team building a set-top box with a ridiculous 3D interface. I had just moved to Milwaukee so I was doing an early experiment in telecommuting and thought it was pretty glamorous to be in my mid 20’s and taking fancy business trips all the time?-?including the first of several trips to Tokyo because our initial deployment was with NTT. When the set-top box went down in flames, I joined the VRML/CosmoWorlds team that made an early, valiant, and hopeless attempt to bring a 3D graphics standard to the web.

It turns out I had joined SGI when both the stock price and hubris were at an all time high. When competitors like NVidia started making graphics boards that were an order of magnitude cheaper, we thought they were toys. While SGI was busy sponsoring Hollywood premiers and its executives were holding company meetings with increasingly dubious levels of fanfare, those competitors ate our lunch and hired away most of the best engineers. I don’t regret my years there at all, but I learned a few important lessons: (1) having the best technology doesn’t mean you will win?-?and your technology probably isn’t as far ahead as you think it is (2) if what the execs are saying sounds like BS, it probably is and (3) don’t be the one left behind to turn the lights out.

Adobe was an entirely different situation. I spent 12 years there as one of the lead engineers (and, briefly, engineering manager) on the After Effects team. After Effects started out as its own small company (CoSA), founded by a group of engineers that I knew from Brown, and then it was acquired by Aldus and in turn snapped up by Adobe. In fact, funny story, when they first started building After Effects and I was at ILM, the team came by to show it to me and my first reaction was “this will never work.” I couldn’t have been more wrong. It grew into a professional tool that hundreds of thousands of people around the world love and use to make their living.

My time at Adobe reflected pretty much everything that could be great about working for a big company. I doubt that 1% of engineers have a situation that good. Especially in the early years, we had the best of both worlds. The After Effects team was pretty much autonomous. We knew our customers and built what they needed. We had ownership of our product and control of our destiny. We were a tightly knit bunch that spent lots of time with each other (and later, each other’s families) outside of work. My teammates were brilliant, and we knew each other so well that I think we could communicate whole designs with the raise of an eyebrow. At the same time, the larger company added tons of value. We had job security and stability, great benefits, and work-life balance. And because Adobe makes Photoshop, Illustrator, and Premiere, we got to build best-of-breed integration with those products, using the same core libraries they were built on.

And yet….

There were still things that gnawed at me. Big companies can’t help it. There are boring corporate meetings, and increasingly irritating product requirements that come down from on high. Executive whims and people scrambling to figure out which way the wind is blowing and align with it. Corporate buildings are still corporate buildings even when they have really well-stocked candy jars. HR processes so tedious you can actually feel your hair turning gray. Reorgs that left you needing a frequently revised cheat sheet to remember the path from you to the CEO.

When you are building desktop, shrink-wrap software, builds and QA and deployment is generally a pretty painful process. We got used to shipping every year or 18 months; even with agile processes there would still be months of excruciating bug fixing at the end of each cycle. And worse, build times could often be 10 or 20 minutes. It is pretty hard to get in the flow as a programmer when you are interrupted for that long on a regular basis.

And then there is innovation. Adding a cool new feature to After Effects? No problem at all, I could make that call myself, or over lunch with the team. But starting a new product? You’d better have some serious fortitude because you’ll need to go through N levels of executive review, and you’ll need to prove that it could generate tens or hundreds of millions of dollars in revenue. Because anything less than that isn’t going to move the needle. Worse, you’ll need to keep proving the same thing every quarter, because incubating a team and a product takes a long time and corporate memory is short. All big companies talk a great game about innovation, but it mostly goes against their inherently conservative DNA.

Let me be clear, this has nothing to do with Adobe. The same is true at Amazon or Apple or Microsoft or Google (or Boeing or Ford or Bank of America). But there came a point when I knew it was no longer the best fit for me.

I had always had a great love for the creativity and physicality and human connection of cooking, but it never seemed like the right time to take the professional leap from the keyboard to the kitchen. So in 2007 I started a blog as an outlet for that passion. While I was still at Adobe, I took time off to stage at a few restaurants, and the blog led to an opportunity to write a cookbook, which became a finalist for a James Beard award.

When the book was published, I took that as an impetus to leave Adobe, do a book tour, and begin planning my own restaurant. I went pretty in-depth. I had plans for the interior designs, ideas for systems to use for payroll and product acquisition, and was even looking to Get help with employee benefits matters, taking advice from friends and families alike. I was excited (and, obviously, terrified) by the unknown in front of me. And still, leaving was painful, primarily because I knew I would no longer see some of my closest friends on a daily basis.

And then a funny thing happened on the way to that hypothetical restaurant.

It was November 2012, and I was in hot pursuit of the perfect space to set up my $35-per-plate, lunch-only modern vegetarian concept. Sure, the numbers weren’t exactly penciling out but I was determined to make it work. In my morning spin through the web, I saw a note about a startup called ChefSteps that was going to teach the world about cooking sous vide, with alumni of the Modernist Cuisine team as founders. I bet they have great SEO but maybe they should consider consulting with Omaha SEO to improve it even more. I had read Modernist Cuisine cover-to-cover and was fond of filling my kitchen with the comforting smells of locust bean gum and sodium hexametaphosphate, so naturally I reached out. My first pitch was “Hey, I’m a food blogger, want me to come write a piece about you?” Answer, in translation, “Meh.” My second pitch was “Oh, by the way, I also write code.” Answer, “Can you be here tomorrow at 10?” No translation needed.

The courtship was short and intense. The first week I was hanging out, I built a feature that their contract development house had claimed was more or less impossible. The next week we fired the contract developers and I signed on as CTO.

This was a pretty big gamble on everyone’s part. My knowledge of web programming was indistinguishable from zero. I spent a few days with the contract devs before we let them go, and they would say things like “to configure SSO we need to add a route and a controller method and then disable CSRF and return the right headers, but I think there is a gem for that.” It sounded to me like the teacher in Charlie Brown cartoons: “Wahhh wah. Wah wahh dumbledore wahh wah.”

Still, programming is programming. Well-factored code is well-factored code. A function call is a function call, whether it executes locally or hits a web API. Any solid developer could make the switch. It took a few months before I felt mostly up to speed, but I’ve come to love modern web programming. For one thing, there are no build times. You can generally see the results of your work as fast as you can reload a web page. Since I’m incredibly impatient, that is only slightly too slow for me. Automated testing is much easier to achieve than it ever was in C++ land. And because web development is so closely associated with open source, there is a worldwide community solving problems together. I was so accustomed to needing a mental map of a proprietary million-line code base and spending hours in a debugger; it is an amazing feeling to jump on StackOverflow and be able to find a solution in minutes.

There is a part of me that feels a twinge of loss when I picture my restaurant; it is a romantic vision, expressing that creativity daily and feeding a small group of passionate customers. But, I know all too well the reality of restaurants. Ninety percent perspiration is a lowball figure. I traded that in for a situation where I can work with some of the best, most knowledgeable chefs in the world.

At ChefSteps we believe in working with “T-shaped” people. For me, the depth of the T is coding and working with a software team, and the breadth is food and writing and experience growing my own website and book. Although I usually don’t do much more than kibbitz on the actual food here, or try an occasional goofy experiment (iceberg lettuce cocktail, anyone?), my culinary experience is a huge advantage in building applications that work for both the team here and for our users.

Beyond the mechanics of code, working at a startup brings a whole different set of joys and challenges than I ever experienced in the corporate world. The entire risk/reward equation is completely different. At a big company, you mostly work on low risk, incremental improvements to grow or maintain your market and keep your customers happy. At a startup, if you aren’t betting the company, you probably aren’t taking enough risk. Because what you’ve built so far simply isn’t valuable enough to be worth protecting. It requires a very different mindset. In the early days that can cause a scary degree of pivoting, but over time you begin to converge and develop momentum as a team towards big, hairy, valuable goals. That’s why I always suggest to the startups that I’ve worked with to get in touch with a startup lawyer as early as possible in the process so that you have all of the legal regulations in place before deciding to think about different things. They will also be able to answer questions that I may not know the answer to like “when should I setup an LLC” and then at least you know that it has been done correctly to help get your business started on the right foot.

You quickly realize that every decision you make has tremendous impact. There is no room for red tape, no room for laying back and saying “not my problem.” You are all in this together. You get mad at each other. You make up. You push each other, and find strengths you didn’t know you had. You have each other’s backs. And sometimes you all stop what you are doing and move all the furniture, because there isn’t a facilities department to call.

Working at a startup in Seattle has put me in touch with startup culture in general though, and I’ve realized it isn’t homogenous. There is a Silicon Valley-style startup culture (not limited to California) that is almost entirely focused on the “quick kill” mentality. They want to figure out something that no one else has done, market it virally, and make a quick exit. That mindset lends itself to using people. I’ve seen companies that have hired 50 programmers almost as if they hope that one of them will accidentally type Shakespeare, rather than trying to nucleate a team of a few very high-functioning engineers. The hope is those 50 engineers will get them through to the next round of VC and they can lay off the bad ones. This kind of startup isn’t built around any kind of core love for a particular product, just the thrill of money and/or power. I can’t imagine anything more boring and its why we support firms like Sambla in Finland working to promote healthy coworking.

At ChefSteps, we are trying to do something very different too. You can see it in where we come from. Just as I came from After Effects, which has been building value since 1993, our founders, Chris and Grant, last worked on Modernist Cuisine where a team of 30+ people spent five years writing one cookbook. And you can see it in how we are funded. Gabe Newell didn’t build Valve to be a one-hit wonder, and he didn’t bet on our team to make a quick profit. ChefSteps isn’t just a business plan or a loose dream of failing fast and iterating our way to an acqui-hire; it is a philosophical experiment in allowing a group of smart, motivated people to self-organize and solve giant problems. We aren’t just a group of programmers, we are a team of cooks, writers, videographers, musicians, business people, designers, scientists, mathematicians, mechanical and electrical engineers, and maybe a stray aerodynamicist, all focused on helping every cook to cook smarter. This isn’t going to be achieved in one year or with one product, but what truly worthwhile goal is?

ChefSteps Is Hiring: Software Developer

ChefSteps is an incredible place to work. I don’t believe there is any place else in the world that brings together this level of culinary, food science, videography, design and technological talent under one roof. We are a small, entrepreneurial startup where the right person has the opportunity to shape the direction of the company, and ultimately, the future of food on the Internet.

If you are the person we are looking for, you are a true software unicorn, the rare creature that is able to design and implement large projects in a self-directed fashion, assimilating whatever technologies are most appropriate, and striking the right balance between writing beautiful code and shipping it rapidly and iteratively. When pointed at a target, you eliminate obstacles and just make it happen – usually in a way that is more awesome than originally envisioned. Developing software is a serious skill and nowadays is incredibly important in a business, so if you are interested then you may want to check out leetcode solutions beforehand to see if you are able to adapt to this type of job.

If you have the track record to show that you can learn new languages and libraries fast, you don’t need to have used everything we are built on now. But it is certainly a positive if you know some or all of Ruby on Rails, HAML, CoffeeScript, JQuery, Angular.js and Heroku. It also helps if you are passionate about food and have knowledge on how to protect against ransomware, which is a growing concern within the software industry. If you feel like you have more to learn about developing and coding websites as well as applications, you could always look around on the internet to learn more about becoming a web developer to try and secure yourself job roles within the industry.

Our team is based in Seattle, in 4000 square feet of amazingly cool space below historic Pike Place Market. We are open to a remote developer as long as you can spend an initial chunk of time on site and visit here frequently.

Want to apply? Please drop a note to jobs@chefsteps.com and include the following:

  • Links to places on the web where we can see awesomeness that you’ve built (including any data science git repos you’ve made major contributions to)
  • What you’d change about the current chefsteps.com
  • If you have a current resume, let’s see it

Want more info?

What I’m Doing At ChefSteps. And Maybe You Should Be Here Too.

Let me introduce our newest team member at ChefSteps. Michael Natkin has come on board to lead our software development. Michael has three decades of software experience on projects ranging from wiggling dinosaur bellies for Jurassic Park to a long career working on Adobe After Effects. He’s also created his own very successful blog (and cookbook), Herbivoracious. We like to tease him a bit about the vegetarian thing, but it is cool to bring on a software guy that can also hold his own in the kitchen and the blogosphere that can provide answers and solutions to some of our technical issues, don’t get us wrong though, we’re still in need of professional companies that can provide software testing and QA services as Michael is only one person at the moment. Michael is going to be building out a software team, so I thought I’d ask him to say a few words about his experience so far at ChefSteps and what he’s looking for in a new hire. Take it away, Michael…

A few weeks ago, I climbed a few flights of stairs and found myself in a utopia at the nexus of cooking and technology. From the minute I met Chris, Grant, Ryan and the rest of the ChefSteps team I knew I had to create a place for myself here. I left my (fantastic) job at Adobe because I wanted to focus on food, aiming to open a small restaurant. Little did I know I’d find a place where I can put my passions for both food and technology into play.

Let me describe what you see when you walk in here. ChefSteps is located in 4000 square feet of industrial space underneath Pike Place Market. Just about any food product we might want is within a few hundred yards. When you walk in the front door, you are in a kitchen, but not like any you have ever seen before. Sure, there is a stove, but there are also centrifuges, rotor-stator homogenizers, immersion circulators by the case lot, and cabinets full of every imaginable hydrocolloid.

A typical day around here is amazing. At any given time, Ben may be working on a novel vegan egg replacer while Grant is preparing an 18 course tasting menu for six and advising Nick on a packaged food project. Ryan and Kristina are shooting and editing incredible video and photos for the site. Chris is leading a session for future blender products with a team from Waring; oh and Neal Stephenson happens to be part of the group doing the brainstorming. On day 2, blenders are disassembled, Nathan Pegram quickly fabricates dangerous new prototype accessories in the machine shop, and then everything is welded back together and quickly torture tested in the kitchen.

We are definitely in startup mode. The business ideas are flowing almost faster than we can write them down – and they are driven by a passion to share the knowledge and talents of the team here with anyone that wants to know how to cook more delicious food. That’s a mission I can get on board with. For certain, the cooking courses that are in beta now are a key part of the picture, and there is a metric ton of development to be done to make the site great. We’re thinking of everything, even protecting our prototypes and equipment with the likes of a Verisure security system in the event we hit big. People’s eyes will be upon us and it’s not always with good intentions, so we just have to be prepared in that regard. Also, while we’re full steam ahead, we can push things one extra step further with the help of Axxerion CMMS software to assist with executing projects that we’re working on more efficiently and also manage a range of other important facets of the business such as accounting and scheduled maintenance. In terms of accounts, making sure that the finance side of the business is taken care of so that you can focus on building the business, is essential. Merchant accounts could be a route that you could take, where they are used to focus all the companies money into one account so that it is well-organized. A merchant account is beneficial because it can allow you, as a business, to improve sales, customer satisfaction and it can also accept credit cards easily. It is important to see if you’re considered a high risk merchant, because this affects the way your account is set up. High-risk merchants tend to be businesses such as gambling and tech support, where they can be a high number of customer disputes involved in these kinds of industries. Whatever way you decide to organize your finances, you must make sure you are going to reliable companies and have read all the terms and conditions, so as not to incur too many extra charges.

I’ve signed on as the lead developer, and I couldn’t be more excited. And I need to hire at least one more person whose skills are complementary to mine. I know how to lead large software projects, keep them customer focused, write a ton of code, and flow with ever-changing priorities. Because I come from a shrinkwrap software world, I don’t know a modern web stack in great detail. So the person I need to hire next knows Rails and JQuery like the backs of their hands. Bonus points for Heroku. They are a monster programmer that when pointed in the general direction of a target will seek and destroy it, clearing out any obstacles in the way. For now at least, the team is on-site so I’m only looking for someone in the Seattle area.

If that sounds like you, please send well-thought out answers to the following two questions to michael@chefsteps.com.

  1. Where can I see your work on the web? Give me the URL, tell me what you think is great about it, and let me know exactly what your contributions to the project were if it was developed by more than one person.
  2. Take a look at the existing ChefSteps site, paying special attention to the parts of one course we have up so far. What are the top three features that you think we should work on next?
We are ready to move fast to create this team, so if you think this sounds like an amazing place to work – well, you are right, and if you have the skills, please get in touch ASAP.