├── .gitignore ├── chapters ├── 0-introduction.md ├── 1-1-what-is-startup.md ├── 1-2-myths.md ├── 1-3-role.md ├── 2-1-defining-success.md ├── 2-2-balance.md ├── 2-3-work-habits.md ├── 2-4-networking.md ├── 3-1-defining-mvp.md ├── 3-2-mvp-strategies.md ├── 3-3-product-workflow.md └── 4-whats-next.md ├── notes.md └── readme.md /.gitignore: -------------------------------------------------------------------------------- 1 | .idea 2 | .DS_Store 3 | -------------------------------------------------------------------------------- /chapters/0-introduction.md: -------------------------------------------------------------------------------- 1 | ## Introduction 2 | 3 | Before Facebook was the Facebook you and I recognize it was a few Harvard students in a dorm room. Before Apple was an iconic American brand, it was two guys named Steve connecting circuit boards in their garage. Many startups come from humble beginnings, but little has been written for engineers who are responsible for building software at these tiny one-room businesses. 4 | -------------------------------------------------------------------------------- /chapters/1-1-what-is-startup.md: -------------------------------------------------------------------------------- 1 | # What is a Startup? 2 | 3 | "Startup" is a term first recorded in [1976](http://www.thecrimson.com/article/2011/11/17/startup-language-idea/) to describe a small, young company with high growth potential. These companies typically leverage technology as an advantage in the market, allowing them to upset or circumvent larger competitors. For example, AirBnb is upsetting the traditional hotel market by allowing guests to book rooms directly with homeowners. Their software and the foundational technology that is now available (ie: the internet) allows them to keep transactions secure and renters safe without the overhead of actually owning expensive property or hiring hourly staff to clean and administer hotels. 4 | 5 | Technology startups may also create solutions to problems so unlike the current solutions that we credit them with making completely new markets. For example, very few people used a "social network" that looked anything like Facebook or Twitter to keep in touch with friends and family before the year 2000. There were "old media" solutions, but the base of technology required for widespread online social networks didn't exist before that time. Once it did, hundreds of competing social networking startups were launched and a new type of business took form. 6 | 7 | While my personal experience is in software, startups aren't limited to that medium. Technology hardware startups created personal computers that acted as the "[first wave](https://venturebeat.com/2016/07/10/what-steve-cases-third-wave-means-for-global-startups/)" in the modern startup movement. These early hardware startups enabled software platforms which in turn enabled internet-connected services to take hold, but hardware startups are far from passe. Advances in "wearable" technology in the late 2000's were largely led by startups like Fitbit and Jawbone before being adopted by larger companies like Apple and Samsung. Even today, hardware startups are playing a huge role in the improvement of 3D printing, unmanned flying vehicles, and self-driving cars. The integration of hardware and software at most of these companies has spawned a new world of valuable and exciting opportunities. 8 | 9 | The problem with startups is that we often don't hear of them until they are no longer truly startups. Many of the companies I mentioned above are publicly traded or have market values in the billions of dollars (commonly referred to as "[unicorns](http://www.ibtimes.com/real-reason-everyone-calls-billion-dollar-startups-unicorns-2079596)"). While I use some examples in this book from companies that are now recognizable names, I'm not writing this book for product developers and engineers who work at billion-dollar startups. For this reason, I've chosen to make an important distinction: this book is about product development at "early stage startups." 10 | 11 | ## What does an early stage startup look like? 12 | 13 | Early stage startups have not yet found [product/market fit](https://web.stanford.edu/class/ee204/ProductMarketFit.html). That means that while the company may have a vision, may have identified a problem, or may have started learning about its market, they are not yet sure exactly how their solution will work or if it will work in a profitable way. Early stage startups are typically experimenting, building prototypes, and talking to customers to get feedback. They're in the "pre-scaling" phase; they need more validation before they can take on large amounts of funding and scale up operations. 14 | 15 | Typically early stage startups are either funded by investors (external parties who are willing to take a risk on the new venture in exchange for an ownership stake), by debt (less common for a startup than a traditional small business, but sometimes founders take personal debt to fund their companies), or by the founders (either from their pockets or through "[sweat equity](http://www.investopedia.com/terms/s/sweatequity.asp)"). 16 | 17 | It's important to note that "early" is a relative term. In a hardware or pharmaceutical startup, you may need to raise millions of dollars just to build a prototype and test it. In a software startup, you probably just need a few thousand dollars or a few hours of your own time to get going. 18 | 19 | While there aren't hard rules about what is an early vs. mid-stage startup, there are some indicators you can use to help determine where your company might fit. Indicators of an early stage startup include: 20 | 21 | - Fewer than 10 full-time employees. 22 | - No funding or just a "seed" funding round. 23 | - The founders are extremely involved in execution, not management. 24 | - Some or all of the employees are foregoing a salary and working for mostly or all equity. 25 | - The business has very few paying customers and mostly "pilot" or "trial" customers. 26 | - The product team is fewer than 5 full-time employees. 27 | 28 | Throughout this book, I'll use the term "startup" and "early stage startup" interchangeably. Just note that unless specified, this book is exclusively about early stage startups. Some of the advice I offer here will work as your company scales up, but some of it probably won't hold up. Office politics, management strategies, organizational charts, and product development are all very different when the founders have their own office than when they sit next to the interns. 29 | 30 | ## How are "startups" different from small businesses? 31 | 32 | The term "startup" is thrown around pretty liberally now. I often hear it used to refer to any small business, and in many ways, the distinctions are minimal. Many organizations that start their lives as startups morph into small businesses, and a few small businesses evolve into startups at some point. The key distinction is scaling potential. [According to Steve Blank](http://www.xconomy.com/san-francisco/2011/09/01/why-governments-dont-get-startups-or-why-theres-only-one-silicon-valley/?single_page=true#) - one of Silicon Valley's most well known venture capitalists, 33 | 34 | > "Scalable startups are what Silicon Valley entrepreneurs and their venture investors aspire to build...From day one, the founders believe that their vision can change the world. Unlike small business entrepreneurs, their interest is not in earning a living but rather in creating equity in a company that eventually will become publicly traded or acquired, generating a multi-million-dollar payoff." 35 | 36 | I don't think that startups' big vision makes them "better" than small businesses, and I don't think that their high failure rate makes them "worse" either. While their _potential_ economic impact may be bigger, most startups never get the chance to materialize into something that "changes the world." 37 | 38 | ## Why do people want to work at a startup? 39 | 40 | It's pretty clear that work at a startup can be exciting. If it takes off, founders and early employees can gain celebrity status, and anyone with a slice of equity will probably get very rich. I know that appealed to me early on in my career. I didn't start planning for retirement [until my late 20's](https://www.karllhughes.com/posts/startup-retirement) because I figured that the equity I had in one of my startups was bound to be worth a few million dollars some day. 41 | 42 | While I'm not as naive anymore, I still love working at startups. Different things appeal to different people, but I think the most common perks are: 43 | 44 | ### Potential impact 45 | 46 | It's hard to overstate how exciting it is believing that your work will help create a completely new market or pave the way for thousands of new jobs in the future. People who can see a startup's potential impact can lose sight of everything else - including whatever they're giving up. 47 | 48 | ### Idealism 49 | 50 | I believe that most people who spend careers in large organizations like the government or publicly traded companies eventually get jaded. Bureaucracy kills innovation and idealism, but startups can (and usually do) live by strict, idealistic codes. Google's first corporate motto was "[Don't be evil](https://en.wikipedia.org/wiki/Don%27t_be_evil)." You don't see mottos like this in most large corporations. 51 | 52 | ### Role 53 | 54 | You might be a big fish in a tiny pond at a startup, but you'll definitely get a bigger role than you would at a large company. I started my first company in college, and while that little startup never got off the ground, I joined another startup after graduation with the title "Director of News," even though the scope of my "direction" was just a handful of interns. 55 | 56 | ### Equity 57 | 58 | "Equity" means an ownership stake in the company, and most startups will offer some equity to early employees in lieu of some or all of their cash compensation. Deciding how to value a startup's equity is difficult, especially in an early stage startup, but I'll just say that I view equity like playing the lottery: if you've got the financial footing to take the risk, it's fine, but don't skip meals just to buy a ticket. 59 | 60 | ### Flexibility 61 | 62 | Another substitute that startups will offer for cash compensation is flexibility. While some of large companies offer work-from-home options, almost every early stage startup lets its employees dictate the terms of their workplace. You might even get "unlimited vacation," although it's probably a good idea to plan on all vacations being "on-call" working vacations at a startup. 63 | 64 | ### Hype 65 | 66 | Finally, there's a lot of hype surrounding startups right now. There's a startup podcast, a startup show on HBO, there have been lots of movies about well-known internet startups like Facebook, and it's hard to read a newspaper without hearing about some magical startup's _machine learning powered, artificial intelligence enabled, 3D printed drone_. 67 | 68 | Before you buy into the hype, before you bank on the million dollar equity payout, read the next chapter in this book. Startups can be a great places to work, but as a product developer or engineer, you have a lot of options for where you can go. Make sure you're making the right decision for yourself before you venture into the startup world. 69 | -------------------------------------------------------------------------------- /chapters/1-2-myths.md: -------------------------------------------------------------------------------- 1 | add: - Dan Lyons' startup bubble 2 | 3 | When I first graduated from college and went looking for a job with a startup I had no idea what to expect. I knew what I didn’t want - I had done internships with some huge corporations already - but finding honest accounts from engineers who had worked at startups was difficult. Most of the articles I found were sugarcoated accounts of the rare success stories. Many of the early employees at Google and Apple and Facebook had written books and blog posts galore, but what about the thousands of less lucky startup employees out there? What about the average startup engineer's story? 4 | 5 | At least [three out of four startups fail](https://www.wsj.com/news/articles/SB10000872396390443720204578004980476429190), and most of them that do succeed don’t have anywhere near the exit that the household names above have had. I suspected - and have since confirmed - that the true experience of working at a startup is much more textured. 6 | 7 | Since college I’ve been working in startups at various stages and I’ve met hundreds of employees at other startups as well. I'm part of a couple startup CTO networking groups, and most of my friends have or do still work for startups. While the glorious fairy tales that come out of the most successful companies might put stars in your eyes, the numbers aren’t in your favor if you think the next big exit will likely involve you. 8 | 9 | That said, working at a startup - even one that isn’t “successful” - can be an interesting and rewarding experience. I’ve seen the downside and I’m still doing it along with thousands of others across the country. Here are a few of the myths I’ve heard as well as some of the truths I’ve learned while working as an engineer for early stage startups: 10 | 11 | ## Myth: you’re going to get a huge equity payout 12 | 13 | The overwhelming majority of startups aren’t big financial successes. Chances are, if you come into a company early on with a bit of equity your stock will be so diluted by the time an exit comes that it won’t make up for the salary cut you took to be there. That is, if you’re lucky enough to be involved in an exit at all. 14 | 15 | If you leave early, are let go for any reason, or are found to have violated any part of your employment agreement, you might lose all of your stock. If you go into a startup as an employee for the money, you’re going to be disappointed 9 out of 10 times. 16 | 17 | ## Truth: you’ll get to set the culture, standards, and technologies used 18 | 19 | Most engineers who come into an existing organization are met with a slew of predetermined rules, established policies, bureaucratic requirements, and “best” practices that you’re unlikely to change. On the other hand, when you come into a startup, almost everything is fluid. I’ve never been part of a startup team that didn’t welcome new ideas and tools if they could be implemented quickly. You are also likely to get some input on the way future engineers are hired and the way your technology team interacts with the business team. These extra-engineering responsibilities can be tough for some to handle, but if they sound like something you’d enjoy, you’ll likely fit right in at a startup. 20 | 21 | ## Myth: you _have_ to work 80 hours per week all the time 22 | 23 | There may be times where it’s necessary to put in extra hours. I know I’ve spent more than a few long nights and weekends coding in my past three years with startups, but those are balanced out by the option to telecommute, lax vacation policies, and flexible working hours when things aren’t as busy. 24 | 25 | You should be ready to sacrifice a bit of your free time - especially if the engineering team consists of just one or two people - but you can’t expect to sustain a grueling 80+ hour work week for long. You’ll need balance in order to avoid burnout, and all but the worst employers will recognize this. 26 | 27 | ## Truth: you’ll have more freedom to choose the projects you work on and how you do them 28 | 29 | Even though you might not be required to spend every weekend at the office, it’s possible that you’ll find yourself choosing to do so anyway. Unlike engineering at a big company, startups often allow you more freedom to choose the projects you work on and how you choose to do them: Want to create the next internal service in a new language? Why not? Want to create your own hybrid framework based on standards you’ve implemented on your engineering team? Go for it. 30 | 31 | These things would be difficult if not impossible to get done in a large corporate environment, but when teams are small, the stakes are high, and people need to move fast, you have more room to try new tools and experiment. An environment that encourages learning and experimentation keeps engineers more motivated than one that stifles its technical talent. 32 | 33 | ## Myth: you have to be a full-stack rock star hacker to work at a startup 34 | 35 | Every time I see a job listing that demands a “rock star” developer who wants to work for shit money at a no-name company, I imagine a non-technical founder on the other end who is bound to underappreciate and undervalue some poor developer who gets suckered into working for him. 36 | 37 | **“Rock star” engineers sometimes work at startups, but usually they work for big companies who can pay them twice the salary and have multiple indoor water polo pools and racquetball courts.** Engineers who work at startups aren’t necessarily hacks, but they tend to come from non-traditional backgrounds, enjoy both the business and technological sides of their work, and have a passion for the problem they’re helping to solve. You don’t have to be a “rock star” - whatever the hell that is - in order to work at a good startup, but… 38 | 39 | ## Truth: you must be willing to learn and teach yourself anything 40 | 41 | You will probably have limited access to mentors and teachers when working at a startup. Big companies put junior engineers through training programs, send them to advanced classes, and make them sit through certification tests, but you rarely see any of those at a startup. Not knowing how to do something isn’t a valid excuse. One of the best skills you can learn if you intend to work for a startup is the ability to figure out things on your own. 42 | 43 | ## Myth: startups are magical machines that are more productive and groundbreaking than large organizations 44 | 45 | You might be exposed to moments of apparent genius while you’re working at a startup, but just as often your team will mistakenly ship something that doesn’t work. **The downside to working for an organization that isn’t bogged down with bureaucracy is that there’s less stuff in place to slow down new bugs as they enter production.** 46 | 47 | ## Truth: startups are constantly facing uphill battles and you’ll rarely have the resources you need to do projects as well as you’d like 48 | 49 | It seems like startups move faster and create solutions to difficult problems more efficiently than large companies, but the truth is that they normally have a lower quality threshold than their corporate counterparts. It’s sometimes difficult to accept this as an engineer because we strive for elegant, well-tested solutions, but the pace at a startup rarely allows for 100% code coverage. If you can live with sometimes letting go of a project that is “good enough” you might be able to make it in a startup environment. 50 | 51 | ## Myth: there’s a lot of risk for engineers at startups 52 | 53 | It’s true that financial circumstances and external forces can quickly shudder a burgeoning startup, but life as an engineer at a large company isn’t a whole lot better these days. 54 | 55 | At least in a smaller organization you’ll (hopefully) have a close enough relationship with the founders to sense that things are looking grim before the doors actually close. Corporations are as likely to sell off a department without more than a week’s notice as they are to give employees severance packages. 56 | 57 | ## Truth: the work environment is fun, the connections you’ll make are invaluable, and the flexibility is unbeatable 58 | 59 | I honestly enjoy coming into work every day. In part it’s because I like and respect the people I work with, in part it’s because I face new challenges and meet interesting people all the time, and finally I enjoy coming to work because I can do it on _my_ time. I’m a morning person, so I normally come in early, take a break in the afternoon to work out, and then leave when traffic settles down a little later in the evening. Some of our team prefers working late into the night. As long as we can all get together when we need to, it’s awesome to have the flexibility to work when you work best. 60 | 61 | I’m not going to lie and tell you that being an engineer at a startup is the best job for everyone. I’m not going to tell you that it will get you rich or make your life stress-free or increase your employability, but I do believe that if you’ve got the right personality it’s far more stimulating than any other job you can find. The opportunity to pursue a cause that I’m passionate about and that improves the state of education in this country makes my job worth the occasional headache, and succeed or fail, I am just glad to be going along for the ride. -------------------------------------------------------------------------------- /chapters/1-3-role.md: -------------------------------------------------------------------------------- 1 | # 1. What is a CTO? 2 | 3 | Before you dive into your goals and start building processes, it's important to understand what exactly it is you do as a CTO. 4 | 5 | ![](http://i.imgur.com/ha70LWv.gif) 6 | 7 | It turns out that this isn't quite as simple to define as you might think. CTOs at startups are in a unique situation as their role will change over time as the company evolves and even in larger organizations, "CTO" is a [relatively new role that has yet to be unanimously defined](http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.158.1721&rep=rep1&type=pdf). 8 | 9 | At an early stage startup, [the CTO is generally a catch-all](https://www.karllhughes.com/posts/roles-of-startup-cto). He will fill in any gaps left unfilled by other product-related employees whether they're engineers, product managers, designers, architects, or QA specialists. This means that a successful CTO at a startup must play many roles in the company, and be ready to learn new skills on the fly. You're not going to be able to hire people to do everything for you on day one. 10 | 11 | Here are just some of the skills you'll want to ready for as an early stage startup's CTO: 12 | 13 | ### 1. Lead engineer for the MVP (Minimum Viable Product) 14 | 15 | Most people who want a technical co-founder probably want someone to help them build or maintain their minimum viable product. On day 1, your most likely role will be to write and ship code. For CTOs with an engineering background, this role will be the most familiar and comfortable, but don't get too used to it. You'll need to break out and look at the big picture as you grow. 16 | 17 | ### 2. Product management 18 | 19 | Most startups I've seen have a non-technical visionary and a product manager in their CTO. The CTO's goal initially might be to make the visionary's ideas a reality, but at the end of the day, someone has to manage this product development process, put feature requests in order, and make sure things adhere to a process. This is where being a CTO with a product management background can pay off. 20 | 21 | ### 3. Technology hiring manager 22 | 23 | Finding the right engineering talent is one of the hardest things that tech startups have to do. Not only do you have to find people who want to work in a small company with fewer benefits and job security; you need to find engineers with specific established skillsets because you won't have time to train everyone on the job. Besides engineers, hiring IT staff, product managers, designers, and technical support people may fall partially in your lap as well. 24 | 25 | ### 4. Security specialist 26 | 27 | How secure are your company's servers? If you came from a development background, you probably have them covered, but what about your CEO's personal laptop that she also uses for work? Does everyone in your company encrypt their hard drives? Use two-factor authentication in their email? Keep their passwords in a secure password vault? These questions are all your job now, so even if you're not truly a security expert, you're probably the best person for this role at your startup. 28 | 29 | ### 5. Application architecture 30 | 31 | MVP's shouldn't rely on complex architectures if they don't need to, but when the time comes to plan for growth, you'll probably find your role shifting from engineer to architect. While you can hire great senior developers to advise you and implement your plan, as the liason between the business and technology teams, you're in the best spot to make high level architecture decisions as they come up. 32 | 33 | ### 6. Technical support 34 | 35 | As a startup grows, it usually finds the need to hire a customer service person (or a remote service), but what happens when this person or a customer finds a bug? It's unlikely that you've built a quality assurance team (see the next point), so it heads to the CTO to distribute bugs to the team accordingly. 36 | 37 | ### 7. QA and testing 38 | 39 | Once again, I've rarely seen an early stage startup with a dedicated QA team or even single person. Small companies usually come up with a system that splits testing and validation work between developers, but that system is implemented by the CTO. 40 | 41 | ### 8. DevOps 42 | 43 | Getting code from the engineers' computers to the servers was once a challenging task, but as automation tools have gotten better, it's possible for developers to spend very little time deploying their code. Still, someone has to own this process, and that will likely fall to the CTO. 44 | 45 | ### 9. Data management 46 | 47 | Big data is hot right now, but data scientists are a luxury that smaller startups usually have to wait on. Even if you can collect millions of data points on your customers, it's useless without someone who can come up with a decent system for storing and accessing this data securely. 48 | 49 | ### 10. Vendor relationships 50 | 51 | We live in an API-driven world. Most software products connect to at least two or three third party services. It's awesome to have so much power at your fingertips as a developer, but as a CTO it's a lot to manage. You have to know who's updated which libraries, which plan you signed up for, and who's got access to your secret keys. 52 | 53 | ### 11. Human resources 54 | 55 | [Managing the growth of a technology team is really hard](http://www.bersin.com/blog/post/2014/07/How-Do-We-Excite2c-Manage2c-and-Retain-the-Tech-Team.aspx). At the beginning you can excite your employees by offering them cool projects with lots of technical challenges, but eventually you'll have to attract more specialized people with benefits, vacation days, and career advancement. You'll also have to make sure people are satisfied in their jobs, that interpersonal issues are handled, and that employees feel valued. 56 | 57 | All of the above roles will be your responsibility at different times as the CTO of a startup, but these roles won't all be necessary at the same time. 58 | 59 | You can think of your role as a circle, where your responsibilities lie on the outer edge of the circle. As the technology team grows, the CTO can back out into bigger picture items, and leave the day-to-day tasks that he initially did to employees whom he trains along the way. 60 | 61 | ### Circles of responsibility 62 | 63 | ![](https://i.imgur.com/7qlleuE.png) 64 | 65 | As the company grows, the CTO will [ideally transition out of a hands-on role and into a true upper management position](https://zapier.com/engineering/startup-cto/). Throughout the rest of this text, I hope to give you some tools that will help you make that transition, but it all starts with personal efficiency. 66 | -------------------------------------------------------------------------------- /chapters/2-1-defining-success.md: -------------------------------------------------------------------------------- 1 | # 2. Defining Success 2 | 3 | Now that you know a little more about your role as a startup CTO, let's look at what it takes to be successful in that role, and how this differs from success in other roles. 4 | 5 | At established companies in roles like product manager or software engineer, your success is usually dictated from your manager. You might have half a dozen KPIs (key performance indicators) or be given a checklist of projects to complete each quarter. At a startup, when you're one of the first team members, you're unlikely to get something this structured. 6 | 7 | As the CTO, you are an executive level team member - even if your job in the beginning is mostly just writing code - so your success is more big-picture than a typical engineer's. This is one of the toughest things for new CTOs to get used to, but nobody is going to tell you with 100% certainty that if you do X, Y, and Z, you will have succeeded in your role. 8 | 9 | The problem is that in a growth company, the priorities are changing too quickly. You can't expect a company with four or fewer quarters of history to predict performance or product initiatives very accurately for the upcoming year. Instead, your success must be more holistic; you msut let go of your desire to crank out more features, lower your defect rate, or ship more code and instead focus on making your company a success. 10 | 11 | ## The Elements of Success 12 | 13 | If the startup you work for gets sold for $100+ million, will you feel like you're a "success?" What if your company falls apart without making any money? What if you get let go by your cofounders or fired by the board of directors? What if you have to downsize in three years? 14 | 15 | I've met startup founders and employees who have gone through all of these scenarios, but despite what you may expect, many of the founders who faced the failure of their company came out the other side looking rather successful as individuals. 16 | 17 | So there are two levels of success for an executive at a startup: 18 | 19 | 1. The success of your company 20 | 2. The personal success of the founder 21 | 22 | You can easily find personal success without starting a successful company because you have [a great degree of control over your own personal success](https://www.karllhughes.com/posts/success-is-in-your-attitude), while your startup's success is [dependant on many factors - some of which you cannot control](https://www.ted.com/talks/bill_gross_the_single_biggest_reason_why_startups_succeed). In the long-term, the success of one or more companies that you start or work for is far less important than your personal success, but most of this book is about the technical and non-technical work you can do to help make your company successful. For the remainder of this section, we'll be talking about habits and patterns you can develop for your own personal success and efficiency. 23 | 24 | ## Personal Success 25 | 26 | It's hard for entrepreneurs - especially those early in their career - to separate themselves from their companies. When I first joined a startup in 2012 I was one of six full-time team members. I would work on projects 10 to 12 hours per day, then answer emails and catch up on administrative work after that. When users were critical of the company or our products, I took it personally, and if my ideas didn't work out, I had trouble admitting that they failed so I stuck with them for way too long. 27 | 28 | Looking back, I can see that this stemmed from my personal insecurities and the thought that if I started my career with a startup that failed, I'd go nowhere. I was naive, out of balance, and unsatisfied with my career. 29 | 30 | After a few years as a member of early stage companies, I have realized that startups come and go, but your health, sanity, and happiness are going to stick with you for as long as you live. You can neglect your personal success in favor of helping your company succeed, but only for a time. I don't believe that in order to work at a startup you have to throw your life completely out of balance, and in fact, I believe that the best and happiest startup employees have realized how to focus on their business while maintaining a successful personal life as well. 31 | 32 | ## Patterns for Personal Success 33 | 34 | If you're looking to find some balance in your life as a CTO, there are some patterns that can help you. These are mindset changes that won't happen overnight, so just reading this chapter probably won't change your world. You may not really absorb them until you've tried it your own way, and maybe you'll strike a balance without them, but here's what I have tried to do to balance my personal success with that of my startup's. 35 | 36 | ### 1. Changes Happen 37 | 38 | If you're used to working in larger organizations, it can be hard to get used to the pace of change in startups. Not only will your company's priorities change as it finds [product-market fit](https://medium.com/evergreen-business-weekly/product-market-fit-what-it-really-means-how-to-measure-it-and-where-to-find-it-70e746be907b#.kmwez7gcm), you'll be faced with new opportunities that will change your roadmap, you'll lose key employees and velocity without warning, your company's founders will come up with new ideas to chase, or someone will want to chase the latest technology craze. 39 | 40 | While it's not responsible to let all these things happen at once - too much change is bad for any team or business - some change is inevitable in an early stage company. Your attitude should be that change is okay. Make it your mission to be the voice of calm in stormy seasons; keep meetings focused even when it seems like the sky is falling; be ready to ride the waves of change. 41 | 42 | There are many things you can do to deal with change in your company. At their heart, many of the personal and product development topics in this book boil down to managing changing priorities in a sane and organized way. Just because things are in turmoil doesn't mean that you have to just let them fall apart. 43 | 44 | ### 2. Think in Terms of Long-Term Success 45 | 46 | When you're running the day-to-day technology operations inside a small business, it's often easy to miss the forest for the trees. Today's problems often overshadow the long-term vison for the company and even your long-term personal success. 47 | 48 | One habit I've gotten into to help keep my brain focused on the long-term is to frequently [visualize what success looks like in the long-term](https://www.entrepreneur.com/article/242373). For me, that long-term success is leading a team in a stable business that I helped build, doing work I love, inspiring and teaching others, and being able to balance a healthy, happy home life. When I get worried about the tiny day-to-day problems that any startup CTO faces - bugs, data loss, downtime - I pull back and ask myself, "Does this really matter that much in my vision for long-term success?" The answer is frequently, "No." 49 | 50 | ### 3. Create Goals Outside Your Business 51 | 52 | If you had to write down five goals for yourself this year, what would they be? Hire a new employee? Finish a big project? Get out from under your legacy code? Write more unit tests? 53 | 54 | All of these are fine goals (although a couple lack the specificity of [SMART goals](https://www.projectsmart.co.uk/smart-goals.php)), but what about setting some goals outside your startup? 55 | 56 | If you're a founder or early employee, you probably tie much of your personal success to that of your business, but this will lead you take things too personally and prevent you from making objective leadership decisions. Your company should be just one of the areas of your life from which you set goals. 57 | 58 | ### 4. Schedule Time for Balance 59 | 60 | If you are keeping personal goals outside your company, you will have to schedule time to achieve your non-business goals. That's where scheduling comes in. 61 | 62 | Look at your typical work week: When do you go into the office every morning? What would happen if you came in 15 minutes later and ran one mile before work? When do you leave the office every evening? What if you left 10 minutes earlier to stop by the grocery store and get something healthy for dinner instead of ordering takeout or heating up a frozen meal? 63 | 64 | Scheduling goes beyond health though. If you've got a family, friends, or other hobbies, you'll have to make time for them somehow. If you aren't doing it intentionally it's easy to fall into the trap of always working. 65 | 66 | We'll explore more about balance in a later chapter, but you probably can free up more time that you never knew you had. In the chapter on Personal Efficiency, we'll explore how batching tasks, focusing on the most important work, and delegating effectively will let you free up more time that you never knew you had. 67 | 68 | ### 5. Consistency Over Time 69 | 70 | "Patience, persistence and perspiration make an unbeatable combination for success." - Napoleon Hill, Author of Think and Grow Rich 71 | 72 | Finally, the most important element to personal and professional success that I've found is consistentcy over time. 73 | 74 | We all know that it's good to eat healthy food right? Yet having a salad once a month won't do much of anything for you. As a software engineer, you've probably heard that you have to keep learning new things throughout your career, right? That's great, but reading a couple books every year likely won't be enough. You're going to need to eat that salad every day for six months or practice that new programming tool every week for a year to really master it. 75 | 76 | This principle of consistency over time carries over into both your professional and personal success, and it's what makes many of the most successful entrepreneurs and leaders attribute their success to. 77 | -------------------------------------------------------------------------------- /chapters/2-2-balance.md: -------------------------------------------------------------------------------- 1 | # 4. Striking a Balance 2 | 3 | I'm a firm believer in balance, but I didn't used to be. When I was younger, I believed that entrepreneurs got ahead by working harder than those around them, so I stayed up late, ignored my personal health, and worked as much as I could. It wasn't sustainable for me, and it probably won't be for you. I know that you may not believe me, but when you're at the edge of your rope and ready to build balance into your life you can come back to this. It'll be here; I promise. 4 | 5 | ## Pushing too hard 6 | 7 | When I was pushing myself too hard, I didn't spend time meeting people or have any time to unwind and actually think strategically. I was constantly moving, so it was impossible to pick my head up and see the big picture. 8 | 9 | If you're moving to a CTO role for the first time finding this balance may be an adjustment. Unlike your work as an engineer, you're going to be expected to know what's going on in the technology landscape - who's hiring, firing, and what other companies just got funded - as well as what's going on in your company's day-to-day. 10 | 11 | Finding the right balance is hard. Every CTO I know who's grown a startup from 5 or 10 people to a hundred has cited this as the biggest challenge. Not only will you need to stop coding once in a while, you'll need to start reading; taking meetings with customers and partners; building a network; and taking better care of yourself. 12 | 13 | ## Where does personal health come in? 14 | 15 | It may seem a little out of place in a book about patterns for startup CTOs, but [your mind (and the body that carries it) is your greatest asset](https://80000hours.org/career-guide/how-to-be-successful/). It's the reason you got picked for this job, and it'll be the reason you stay in it or the reason you move on to something better someday. If your business is picking up steam, but your personal health is in freefall, you won't have the stamina to stay in the game when your company hits an inevitable speed bump. 16 | 17 | Scott Adams, a writer, engineer, and the creator of Dilbert has [this to say about fitness](http://blog.dilbert.com/post/103051087451/health-as-a-competitive-edge): 18 | 19 | > "Fit people have more energy to put into every task. And we all know that humans perform better when they have more energy. Studies back that observation...Energy influences your optimism, your ambition, and how others see you. Those are big deals too." 20 | 21 | So [make a long term investment in yourself](https://www.karllhughes.com/posts/health-investment-success) by eating well, working out at least three times per week, [sleeping 7 to 8 hours per night](https://codewithoutrules.com/2017/07/07/dont-code-at-2am/), and avoiding excess. 22 | 23 | ## Financial success beyond the IPO 24 | 25 | If you're in your 20's working at a startup, your retirement plan is probably to cash in all those sweet, sweet shares once your startup goes for an IPO (initial public offering). This is a [terrible long-term financial plan](https://www.karllhughes.com/posts/startup-retirement). Even a significant amount of equity in an early stage startup will get diluted, exit events are pretty rare, and without one [that stock may never turn into cash](https://www.quora.com/If-a-startup-doesnt-issue-an-IPO-isnt-acquired-will-an-employees-equity-ever-be-worth-anything). Finally, most employees get "Common Stock" which means that they won't get any payout [until after investors have made their money back and more](http://stockoptioncounsel.com/blog/negotiating-equity-what-is-the-total-preference/2014/2/13). While equity can be a great cushion for your portfolio, it's never a good idea to put all your eggs into one basket. 26 | 27 | Fortunately, creating a financial plan is easier now than ever before. There are a ton of great resources available (check out the end of [this article](https://www.karllhughes.com/posts/startup-retirement) for some of my favorites), and financial management software tools are cheaper and more accessible than ever before. Invest a few hours figuring out how much you can save outside your startup and you'll thank yourself when you actually get to retire someday. 28 | 29 | ## Social time 30 | 31 | I still struggle with this, but social interactions beyond your job are an [important part of personal mental health](https://www.nia.nih.gov/about/living-long-well-21st-century-strategic-directions-research-aging/research-suggests-positive) and success. I have been lucky to work with great people at startups over the past six years, but I've also made a concerted effort to spend time with people outside my businesses. Professional groups, sporting events, concerts, and clubs are all great ways to find a consistent group of peers to socialize with. 32 | 33 | Another habit I've gotten into is meeting a new person every week. It doesn't have to be a really deep meeting - just starting a conversation with a person in line at the grocery store counts in my book - but the feeling of connecting with a new human is exciting and it makes me more open in other parts of my life as well. 34 | 35 | Meeting and staying in touch with people is its own topic though, which is where the next chapter takes us. 36 | 37 | ----- 38 | 39 | https://www.karllhughes.com/posts/working-hours 40 | 41 | ----- 42 | 43 | ### 3. Batching, focusing, delegating 44 | - https://en.wikipedia.org/wiki/Personal_software_process 45 | - 4-Hour workweek 46 | - Write down ideas, don't pursue them immediately 47 | - https://www.karllhughes.com/posts/training-for-focus-four-ways-eyes-big-picture 48 | - Personal kanban 49 | - Reading list 50 | 51 | ### 4. Dealing with fear and uncertainty 52 | - If it's painful, do it more often (eg: deployments), you'll find a way to automate it. (Martin Fowler?) 53 | - https://www.karllhughes.com/posts/are-you-placing-the-blame-internally-or-externally 54 | 55 | ----- 56 | 57 | # 3. Dealing with Fear and Uncertainty 58 | 59 | I remember vividly the feeling I got when I was put in charge of my first real team of engineers. I got pulled into an unscheduled meeting with our CEO and COO on a Wednesday afternoon. They told me that my boss - our company's Head of Engineering - was leaving in two weeks and that they wanted me to take over his role. 60 | 61 | I had managed small teams of writers in college and just afterward, and I started this job managing a couple contractors overseas, but leading and building our engineering team of five at a quickly growing startup felt like a big leap. How would I get the team to respect me? I was younger than most of them, and hadn't really been a developer that long. Would I have the courage to stand up for their interest in company meetings? How would the new engineers feel about getting a new boss just after they started work? 62 | 63 | The company's makeup had dramatically changed over my first year and a half there, and now, just as things were starting to stabilize and our engineering team was picking up steam, our leader was moving on and I was going to have to step up. 64 | 65 | I'm an ambitious individual, so you might think I was excited - and maybe part of me was - but the only feeling I vividly remember was fear. 66 | 67 | I walked out of the meeting with the founders a bit shaky and tried to focus on getting some work done for the rest of the day. I went home and kept my girlfriend up late talking about what I should do and how I was going to deal with this new role. I felt completely unprepared and uncertain. 68 | 69 | ## Imposter Syndrome 70 | 71 | I've talked to countless CTOs and engineering managers since then, and I now realize that this feeling of inadequacy is far from exceptional. In fact, [most people will have this feeling at some point in their career](http://bsris.swu.ac.th/journal/i6/6-6_Jaruwan_73-92.pdf), which is why we have a name for it: imposter syndrome. 72 | 73 | I'm not going to try to give you a cure-all for this feeling. If it's your first time managing a team, you're probably going to get it at some point, and hopefully you have a supportive network of mentors within and outside your company to help you out. 74 | 75 | That said, here's what has helped me keep imposter syndrome from paralyzing me: 76 | 77 | ### 1. Talk through the feelings 78 | 79 | Having people around you who you trust and can go to when you feel overwhelmed or unworthy is the biggest career asset you can have. I have a few close mentors who are years ahead of me on the leadership journey, a wonderful fiancee who also holds a position of leadership in her profession, and have had great coworkers at various places along the way. 80 | 81 | It's hard to admit that you don't feel adequate for your job, but it's okay. Remember 70% of people have felt this way, so chances are that your support network has been in your shoes. 82 | 83 | ### 2. Keep the big picture in mind 84 | 85 | Going back to my point in chapter 2, most of the little decisions you make during a typical week are not actually as big a deal as you think they are when you visualize the big picture. Your company may succeed or fail, but it's unlikely that you will be the sole root cause of either of those. If you feel like you are, ask your leadership team how they feel about it. If they feel like you're the right person for your job there's probably a reason for it. 86 | 87 | ### 3. Be honest with your team 88 | 89 | Finally, I am honest with my teammates in one-on-ones and group settings. When I don't know the best decision to make, I tell them. This is a sign of humanity, not weakness, and it increases their empathy for you as a leader. It also gives them a chance to step up and help you out if they know you feel a bit overwhelmed. 90 | 91 | MORE ON THIS: https://medium.com/@FlatironSchool/youre-not-an-impostor-how-to-manage-self-expectations-as-a-new-developer-cf8285e04a5e#.xad993rm9 92 | 93 | ## Uncertainty 94 | 95 | Leaders often must make decisions with incomplete information. When I joined The Graide Network in 2016, I spent a lot of time talking with the founders about the requirements of their platform. The first version was unreliable and had fundamental flaws in the way data was stored, so like many companies dealing with a legacy software stack, we faced a choice between rebuilding or refactoring. 96 | 97 | Rebuilding meant we could throw the mess out and restart the project based on the features we knew it had to have. We could eliminate inefficiencies, unit test everything, and in three to six months, probably be back where we started. 98 | 99 | Refactoring would be a longer, but likely safer road. Every project has the spec that engineers know about and the spec that is locked away in the business team's mind. What I mean is that even if we attempted to catalog all the features of The Graide Network's platform, we'd constantly be discovering or remembering new ones. 100 | 101 | This system was over a year old and had undergone many upgrades, so things were patched on top of each other in a way that made relying on the code for spec nearly impossible. Rebuilding from the ground up would likely take longer than we thought, and making reasonable estimates was impossible. Plus, we'd have to maintain the older system while the new one came online, and that would only slow things down more. 102 | 103 | I did not have a template for dealing with this kind of problem yet, and the rest of my team was not technical, so they really didn't know where to start. This wasn't my first time dealing with uncertainty though, so I had an idea of where to start with making this decision. 104 | 105 | ### 1. Gather details 106 | 107 | Details of a problem come in two flavors: technical and non-technical. Gathering them can mean talking to team members or customers, reading articles or books, or even trying one or two things out. Pulling together information is a great first step in conquering uncertainty, but here's the catch: you have to set a limit for yourself. 108 | 109 | "[Analysis paralysis](https://www.forbes.com/sites/jeffboss/2015/03/20/how-to-overcome-the-analysis-paralysis-of-decision-making/#90402931be5a)" is a term used for being unable to act because you're so focused on gathering or analyzing data that you can't commit to a path. The reason you don't want the detail gathering phase of your decision making to take too long is that at a certain point, you really can't absorb and weigh any more information than you already have. Set yourself a time limit, go learn all you can about your problem, then move on. 110 | 111 | ### 2. Talk to your mentors 112 | 113 | While a great mentor might not have a solution to your particular problem, they'll usually help you put it into perspective or help you remember your priorities. 114 | 115 | A while back I was weighing letting an employee go. He was hired to do a very specific job and was mostly self-managing his priorities and timeline (that hire itself was a mistake on my part, but that's another story). He had made some progress, but he was constantly overbuilding things, and it was a huge drain on our velocity. We were a startup, so perfection wasn't the goal; pragmatism was. 116 | 117 | Anyway, I met with a couple of my mentors about it, and one of them immediately pointed out my flaw in hiring him. "You hired someone to do X? And you've only got 6 engineers? No, no, no. Quit that now." 118 | 119 | The employee's performance was my concern, but in reality, the biggest problem was that I had hired someone for a job that wasn't necessary yet. Stepping back and hearing this from someone who had more experience and wisdom than me was of huge value. 120 | 121 | ### 3. Balance reasoning with your gut 122 | 123 | In Richard Wiseman's _The Luck Factor_, one of the things that he found in common among lucky people was that they knew when to listen to their "gut" rather than reasoning through every problem completely. Like any common muscle action - typing on a keyboard, turning a page in a book, or putting on your clothes - your brain has learned to put these tasks on auto-pilot. You don't really think about them. At a certain point, your brain relies on this same auto-pilot to help it make decisions based on past experiences you've had that you don't even consciously remember. 124 | 125 | I know that as a first-time engineering manager or CTO, you might not think your gut is the best decision-maker, but you might also be surprised. Many of the same problems you faced as a software engineer or team lead have prepared you for making good gut decisions. 126 | 127 | Most importantly, remember that fear, uncertainty, and imposter syndrome or normal reactions to taking on a new role. Your brain is telling you to back off and go back to something comfortable. Don't let this hold you back. Learn to face struggles with action and keep moving forward. It only gets easier. 128 | -------------------------------------------------------------------------------- /chapters/2-3-work-habits.md: -------------------------------------------------------------------------------- 1 | # 5. Batching, Focusing, and Delegating 2 | 3 | Effective engineering managers must first learn to be effective and efficient engineers. If you're spending every day as a CTO spinning your wheels by bouncing between meetings, answering questions, and things aren't getting done, you've got a problem. 4 | 5 | I've found three ideas to be essential for improving my personal productivity as an engineer and engineering leader or CTO. While your strategy for doing these same things may be different, you must learn to focus, batch, and delegate tasks. 6 | 7 | 8 | ## 1. Focusing on the Most Important Tasks 9 | 10 | > "You may need to do fifty things a day in New York, but I’d rather to do some reading in my office and do one to two things a day and do them well," - [Warren Buffet](https://www.americanexpress.com/us/small-business/openforum/articles/successful-entrepreneurs-secrets-to-mastering-work-life-balance/) 11 | 12 | Prioritization is one of the hardest things for startups to do. I think the reason for that is undisciplined founders. For most of their career, they've been forced to go at someone else's speed, obey the rules, and plod through bureaucracy. Now that they've got their startup though, things can change as fast as they can dream them up. This "everything's a priority" feeling will trickle down to you as a CTO and the engineering team you manage, so you've got to be ready. 13 | 14 | For example, early in my career I worked at a startup where the founders were young. Investors had given us some money and we had an early version of the product out in the world, but it wasn't taking off like we'd hoped. We didn't have a roadmap; just hypotheses about what would work, and so every day our developers were asked to build new features or pull out existing ones because maybe that would be the magic switch that turned the company around. 15 | 16 | Every time an idea came in, it was immediately the most important thing on the table, and all other half-built projects came to a halt. Needless to say, this led to a very poor product and a lot of burnt out employees. Until we hired an engineering/product manager to stem the flow of new ideas and try to organize things, we were running in circles getting very little accomplished. 17 | 18 | Now, some of those issues were business issues; some were personality issues; but either way, as the CTO at your startup, it's your job to figure out how to prioritize the flow of ideas from founders, investors, and advisors. 19 | 20 | Ideas are cheap. They're easy to produce, and when you start generating them it actually becomes easier to make more. This idea-generation cycle can be challenging for engineers because our work tends to take longer, be more methodical, and need follow-up time to improve. In other words, new projects are rarely completed on their first release; we need time to iterate. 21 | 22 | This applies to how you prioritize things for your engineering team, but it also applies to how you prioritize things in your personal workflow. It may be that before your startup has a lot of cash you're the only engineer, and if that's the case prioritization is one of your biggest assets. I'll talk more about product and engineering prioritization later in this book, but for now, let's see what it means to have your personal priorities in order. 23 | 24 | ### Personal Prioritization 25 | 26 | What was the most important thing you did last week at work? What are the three most important things that you've got to get done this week? How many hours did you spend working on them? 27 | 28 | You need to be able to answer these questions. 29 | 30 | When you're working in a startup as one of the first employees there will be a million opportunities, meetings, and ideas to discuss in addition to articles to read, meetups to attend, and people to meet. While networking and public relations _are_ an important part of an early stage CTO's job, they can't get in the way of the most important tasks you have every week. Here are a few steps you can take to make sure you get your personal work priorities right: 31 | 32 | #### 1. Make a to-do list 33 | It's one of the oldest tricks in the book, but it really works. Make a list each week of all the things you want to get done. Make sure your list is reasonably attainable and prioritized from most important to least important. 34 | 35 | #### 2. Look at your list every morning 36 | Those are the items you need to work on first. Don't come into the office or open up your laptop and get sucked into emails or Linkedin messages for an hour. That can wait. Instead, spend your first two or three hours of really productive time knocking something off your all-important list each morning. 37 | 38 | #### 3. Track your time 39 | I never knew how I was spending my time at work until I downloaded a time-tracking app for my smartphone. Every time I switched tasks I would update the app, and at the end of the week I'd check my time breakdown to see how productive I really was. It might surprise you how little time you really get to spend writing code when you're interrupted by questions or meetings every two hours. 40 | 41 | 42 | ## 2. Batching Similar Work 43 | 44 | While tracking what you're doing and keeping an organized list of your priorities will help, you will still inevitably have to do some housekeeping tasks. Answering emails, responding to Slack messages, reviewing pull requests, etc. all take time, but they probably aren't your top priorities for the week. 45 | 46 | Batching is a great trick to make those tasks take less time by waiting longer between doing them. 47 | 48 | What do I mean by "batching"? Let's look at a simple example. 49 | 50 | If you were asked to track the amount of time you spend checking and responding to email every week, you'd find that you probably do it way more often than you think. What do you do when there's a lull in a meeting? How about when you're waiting on someone to meet you for lunch? Email is always there, so it's easy to just hop on your phone and see what's new. 51 | 52 | The thing is that 99.9% of a CTO's emails don't have to be answered immediately. If you're honest with yourself you could probably wait until the end of the day or at least until lunch to respond to most of them. Many don't even require a response at all. 53 | 54 | So what can you do to stop wasting time on email? Do it less, but budget a block of time for it every day. 55 | 56 | Turn off the notifications on your phone and laptop so it's not constantly pinging you, and just set yourself a single once-per-day calendar reminder to check your email at 5pm. Spend 30-60 minutes on it and then leave it until the next afternoon. 57 | 58 | Try it for a week and you'll be amazed how much more productive you are during the day. Uninterrupted blocks of time are the key to being a productive developer, so while you're still in charge of writing code or other high-concentration tasks, batch all your smaller tasks and relegate them to specific time slots throughout the week. 59 | 60 | Another good example of batching is how you read news or blog posts. If you read every article that comes into your social feeds as soon as they appear you'll waste way too much time hopping around the web chasing news. Instead, keep a list of links to articles you want to read and set aside an hour every week to sit down and really read them. Not only will you comprehend your reading more this way, you also won't get distracted by every news article that flies at you. You can always read it later. 61 | 62 | 63 | ## 3. Delegating Effectively 64 | 65 | A couple of years ago I got to meet and learn from [Nick Sarillo](http://www.nicksarillo.com/), a Chicago restraunt entrepreneur who's been repeatedly recognized for turning out successful restaurants and having engaged, interested employees. Like most new managers, Nick struggled with delegation when he was new at it too. He would try handing off important tasks to his team and then when someone dropped the ball he'd kick himself for not just doing it on his own. 66 | 67 | Nick spent a lot of time figuring out delegation though. Unlike a one or two-person software startup, you can't run multiple successful pizza restaurants without being able to delegate, and since many of Nick's employees are high school or college kids, he's really had to think about how he can do it while keeping their chances of failure low. 68 | 69 | This framework really resonated with me as a new manager. I have always struggled with giving important tasks to other people. While reading the words here won't fix all your problems, I hope you can take this framework and start using it to build your own system for delegation. 70 | 71 | ### A Framework for Delegation 72 | 73 | #### What 74 | The most obvious spot for delegation to fail is in the "What needs to be done" phase. As a manager, you must outline the expected result in no uncertain terms, and you can't assume that your employees know the same context that you do. Remember, they probably aren't in the same higher-level business meetings as you, so they may not know exactly what you expect from them. 75 | 76 | I find this especially important when delegating open-ended research tasks. For example, if I wanted an employee to evaluate a new programming language, framework, or library, I wouldn't give them a task to "Evaluate X". I'd give them a matrix of things I wanted to know about the different options and ask them to fill it out. 77 | 78 | Yes, defining a specific "What" like this takes more time than being vague, but the results - the thing we really care about - are much better. 79 | 80 | #### Why 81 | You can never give too much context, even when you're just giving an intern a task to complete. Employees will feel more connected to the organization when they understand why they're doing something, and I think this is one of the areas where startups can shine compared with larger corporations. 82 | 83 | Large companies have the disadvantage of many layers of management, so the average employee has been told to do something by his manager who was told by her manager who was told by his manager, and up the chain until nobody really knows why they're doing anything. 84 | 85 | When you delegate even a simple task, continually stress _why_ you're delegating it, _why_ the company needs it done, and _why_ the person you chose is the best one for the job. 86 | 87 | #### Who 88 | You might think this one would be obvious, but I've walked out of meetings before where we all agreed that "X needs to be done," only to realize at our next meeting that noone was actually assigned to be responsible for doing it. 89 | 90 | Just because you mention a task or idea in a meeting does not mean your team will take the suggestion and run with it. You have to explicitly delegate each task to a project owner who will ensure that it gets done. 91 | 92 | #### How 93 | Be honest, even if you don't want to micromanage someone, as the most senior engineer on the team you may have a really good idea how every task you delegate should be done. If the task is a large one, you may only have a strong opinion on how they complete certain parts of it. Either way, it's your responsibility to define this. 94 | 95 | For example, if you have a new feature that you're going to delegate to an employee, you should spell out things even if they seem obvious. For example, where in the code should this feature live? Should it be tested? If so, how thoroughly? What other features might this affect? What can the employee do to minimize side effects during the development of this feature? 96 | 97 | Once you have worked with someone a long time they may start to know how you think well enough that you don't have to be as explicit with them, but [it rarely hurts to constrain projects more tightly](https://www.fastcompany.com/3027379/the-psychology-of-limitations-how-and-why-constraints-can-make-you-more-creative). 98 | 99 | #### When 100 | Is this project supposed to be done by your meeting next week? Do you need your employee to give you a progress report in three days? If there are time constraints - and any project that is actually going to get done will have time constraints - then set them explicitly. Your cofounders or CEO may be bugging you about something that you've delegated, but the person you delegated to won't feel that same pressure. Instead, just make sure they know what you expect. 101 | 102 | I also find it helpful to come up with timelines for projects together rather than to dictate them from the top down. For example, instead of telling an employee that they need to complete a feature by Friday, ask them when they think they can be done. If they say the following Monday and you need it by Friday, dig in and figure out what the employee will have to offset to make you meet your deadline. If you set mandated timelines from the top that never get met, people will never respect them. 103 | 104 | #### Check for understanding 105 | Up to this point, I've made it seem that delegation is a one-way street, but that's not the case. As the manager delegating a task, it's your job to make sure it is fully understood and gets done. This may mean sitting down with the employee and having them parrot back your expectations or it may simply mean getting a verbal "Yes." This depends on how long you've worked with the person and how well you work together. 106 | 107 | My process for delegation is to write out a short specification using the five question words above ("What", "Why", "Who", "How", "When"). Before I assign work out to an employee, I sit down with them and have them read the spec and explain it to me. This helps us uncover more unknowns and potential issues. Finally, as they work on it, I set checkin points to make sure they still feel confident in their estimated completion time and that they still understand the project. 108 | 109 | #### Benefits and consequences 110 | Sometimes the benefits of a project or task are well-understood and sometimes they're not. Sometimes they are already covered in the "Why" section above, but sometimes they're under the surface. Either way, make sure that you give your employees a summary of the benefits if they successfully complete the project as well as the consequences if they don't. 111 | 112 | When I say "consequences" here, I'm usually not talking about an ultimatum. Some managers might be able to do the whole, "fix it or you're fired!" thing, but that's not my style. When my employees are working on mission-critical projects I explain to them how their work will have an impact on the startup and how we all will benefit if it's executed well. If not, we may miss a deadline, lose out on serious sales money, or lose the trust of our fellow team members. All those are bad enough that you don't need to hang someone's job over their head. 113 | 114 | If you're interested in learning more about focusing, delegating, or batching tasks, get your hands on a copy of The Four Hour Workweek. While Tim Ferris' title might be a little gimmicky, it has some really good tips for making the most of your time and becoming more efficient. 115 | -------------------------------------------------------------------------------- /chapters/2-4-networking.md: -------------------------------------------------------------------------------- 1 | # 6. Networking 2 | 3 | How do you get a job as a CTO at a startup? When you do get one, how do you find people to hire? Once you've hired some people, how do you keep up with what's going on in the greater ecosystem? 4 | 5 | Every job I've had besides my first internship in college came from someone I knew. I got my second internship because I knew another intern there from my engineering fraternity, my third internship was with a couple of friends I went to bars with regularly, my first job at a startup came after attempting to partner with them, and my next two jobs leading engineering teams at startups came from meeting founders at pitch events and keeping in touch for months. 6 | 7 | [Networking is extremely valuable](http://firstround.com/review/how-to-become-insanely-well-connected/), but it rarely bears fruit from day one, so I think a lot of people give up on it quickly. For some reason we accept that personal and romantic relationships take time to build, but business relationships are dropped as soon as we don't see a reason for them. Networking doesn't have to be slimy; it's just a fancy word for maintaining and building relationships. Often there's not a quid-pro-quo to be had, but that's okay. Every once in a while someone you know is the perfect person for something you need, or vice versa. That's when your network pays off. 8 | 9 | ## What is networking? 10 | 11 | First, networking is not necessarily going to designated networking events to shake hands and make friends. I've tried this, but it feels unnatural to me, so I've developed a different approach. 12 | 13 | ### 1. Attend community events 14 | 15 | If you are fortunate enough to live in a big city, there are probably dozens of professional groups that you can get involved in. If you're in a smaller town, keep a look out for virtual opportunities to get facetime with new people. Conferences, Meetup.com, clubs, and sports leagues are all great ways to branch out, so pick whatever you're most comfortable with. 16 | 17 | ### 2. Follow up with people 18 | 19 | The key to attending events and making them productive is to follow up with people you meet. If you go to a meetup, shake hands with three or four people, and then never follow up your chances of making a meaningful connection is low. I've always had the best luck following up with a coffee or lunch meeting, and then taking it from there. 20 | 21 | ### 3. Say yes to new opportunities 22 | 23 | Get in the habit of saying "Yes," when people invite you to things. I know, it's uncomfortable and risky and it might be a waste of time, but this is how you discover new groups of people. I'm not a party person, but I try to tag along with a friend to one or two group outings per month just to expose myself to new cliques. 24 | 25 | ### 4. Give back 26 | 27 | Finally, volunteering, teaching, or speaking are all great ways to meet new people. If you've ever been to a conference you probably know that the best way to meet people is to be a speaker at the conference. Similarly, doing a guest lecture for a school or code bootcamp can put you in front of a totally new group of developers. Not only is this good for you, it's great for your company's long term brand. 28 | 29 | ## A system for keeping in touch 30 | 31 | I first started using a system for keeping in touch with important people in my life in college. I realized that if I wasn't intentional about it, I wouldn't be able to keep up with a few dozen coworkers, mentors, friends, and peers, so [I started keeping a list of people]( 32 | https://www.karllhughes.com/posts/the-key-to-networking-keeping-in-touch) who I wanted to stay in touch with. 33 | 34 | I try to keep the number of people to less than 50, but sometimes it spills over a bit. In order to keep up with them, I set a reminder in my calendar to send each of them a personal email every three months. 35 | 36 | Does this take a lot of time? Yes. 37 | 38 | Is this worth every second? Also, yes. 39 | 40 | ### A guide to making your own quarterly contact list 41 | 42 | #### 1. Figure out who should be on your list 43 | 44 | Go through your LinkedIn contacts, Facebook friends, and Twitter followers looking for people from your network who you want to keep up with. Don't just choose people based on what they can do for you; choose people with high potential who are both above and below your professional level. Good networkers help more than they receive help, and you never know when that kid who just graduated might turn out to be the next Mark Zuckerburg. 45 | 46 | #### 2. Choose the best way to contact them 47 | 48 | If you've emailed with them before, this is probably the best way to get in touch with them. If you've only talked to them on the phone, that's your ticket. Try to take your communication off of social media, but if you have to, send them a Twitter or Facebook message. 49 | 50 | #### 3. Save one piece of personal information about your relationship 51 | 52 | My quarterly contact list has 4 columns: name, email, phone number, and relationship information. That last column is important because that's where I keep a record of the last thing we talked about or the last personal update I got from their life. You'd be amazed how excited people get when you send them an email and actually remember that they just had a baby 6 months ago. 53 | 54 | #### 4. Make a clear and unavoidable reminder 55 | 56 | It's easy to forget to send everyone in your contact list a message every three months, so make your reminder unavoidable if possible. I set up a Google calendar event with an email alert to tell me when it's time to reach out to everyone on my list, but you should choose the method that works best for you. If you don't have a failsafe method, try [Follow Up Then](http://www.followupthen.com/) for making your reminder. 57 | 58 | #### 5. Don't just ask for something 59 | 60 | When you send each person in your list a personal email, it's okay to mention what you're working on, but it's not okay to simply ask them for something. Instead, ask them about what they're doing; offer to help them; show interest in their life. Good networkers help more than they ask for help. 61 | 62 | #### 6. Reserve time to send and respond to emails 63 | 64 | A lot of people avoid doing this because they don't want to invest the time required to follow up and read all the email messages that they'll inevitably get back. That's an extremely short-sighted way of looking at things, so reserve a day or two to read and respond to everyone individually. They'll be impressed with your effort, and know that you care enough to make time for them. 65 | 66 | Building and maintaining relationships with professional contacts takes time and effort, but if you take a focused approach, it shouldn't be hard to do. If you've got your own tips for keeping up with people, feel free to leave them in the comments below. 67 | -------------------------------------------------------------------------------- /chapters/3-1-defining-mvp.md: -------------------------------------------------------------------------------- 1 | # 2. Developing an MVP 2 | 3 | "It's more about understanding what to build and if it’s worth building instead of how to build it" - [Thomas Trajan](https://medium.com/@tomastrajan/how-can-you-increase-your-value-as-a-software-engineer-cab9599bbbe) 4 | 5 | ## What is an MVP? 6 | 7 | For most entrepreneurs with an idea it’s hard to compromise on quality. In their mind, the product or service they want to deliver is top-notch, but in reality they rarely have the resources to build anything like what they imagine. 8 | 9 | The term MVP, which stands for “minimum viable product” gets thrown around all the time in startups. It was popularized by Eric Ries in his book The Lean Startup (http://www.startuplessonslearned.com/2009/03/minimum-viable-product.html), which is well worth the weekend it will take you to read. 10 | 11 | The goal of an MVP in business development is to create something that meets just enough of the business need to test or validate an assumption, allowing the entrepreneur (or intrapreneur) to save on scarce resources until the project is proven “viable.” In The Lean Startup, Ries says that an MVP is “not necessarily the smallest product imaginable...it is simply the fastest way to get through the Build-Measure-Learn feedback loop with the minimum amount of effort.” 12 | 13 | So an MVP is less about building a product, and more about [learning what your product needs to be](https://steveblank.com/2013/07/22/an-mvp-is-not-a-cheaper-product-its-about-smart-learning/3-1-defining-mvp.md). I think of the MVP as a “pre-product” phase. Some good examples of an MVP might be: 14 | 15 | - A software as a service company runs a pilot service with three paying customers using spreadsheets, online forms, and email. 16 | - An app maker creates mock-ups of his app, creates a free landing page website, and measures the number of people who click the “Download Now” button. 17 | - A writer releases the first three chapters of his book and directs potential buyers to fill out a form with their email address if they want to know when more is released. 18 | 19 | There are [dozens of ways you can build an MVP](http://mlsdev.com/en/blog/50-types-of-mvp), but you might have noticed that none of the examples above require work from a software developer. This is intentional. Software is expensive to build and maintain, so an ideal MVP requires no dev work to get out the door. This allows the business team to learn whether or not their idea is viable before they invest heavily in product development. 20 | 21 | 22 | ## Where Does the CTO Fit In? 23 | 24 | An early stage CTO who's building an MVP has the job of figuring out how to piece together a "product" that will prove the business' viability as quickly as possible. 25 | 26 | Notice that I didn't say an early stage CTO should write a custom CMS, build something in the latest exciting framework, or even write code at all. If you are a software developer then great. You'll have an advantage over startups whose head of product or engineering is less technical. Still, that doesn't mean you should spend a ton of time writing code in the beginning. 27 | 28 | Once the business has tested its hypothesis and you're ready to invest in a more robust product, your job will change. You'll need to break out your architecture skills and make decisions about what kind of tech stack to use, the kind of team you want to hire, and the product release cycle you want to employ. In the MVP phase, these decisions don't really matter much. 29 | 30 | The truth is that many software startups in the MVP phase [don't need a developer to figure out if their idea is viable](https://www.karllhughes.com/posts/creating-a-tech-startup-without-a-developer). They need a way to put their idea into the world, and [plenty of low-cost tools exist for exactly that purpose](http://blog.stridenyc.com/blog/you-dont-need-a-cto-you-need-squarespace/). 31 | 32 | 33 | ## Minimal MVPs 34 | 35 | > "Premature scaling is putting the cart before the proverbial horse, and in the case of startups this can potentially relate to both engineering and operations...For the engineering team, there’s the often obsessed about notion of having a robust platform that can handle millions of users before the startup even gets to 10’s of thousands on there. The team starts to worry about all the technical issues that they’ll have to deal with when success comes, but they lose track of what is actually going to make them succeed." - [Michael A. Jackson, Advent Venture Partners](https://www.linkedin.com/in/michaeljacksonvc/) 36 | 37 | Many software engineers get stuck in the mindset that a product isn't "good" if it wasn't well-built, tested, and professionally engineered, so I'm devoting the rest of this chapter to show you how real companies have built MVPs with little to no custom development work. These solutions aren't meant to carry a startup through to millions in revenue or "scale", but [more startups have been burned by premature scaling than have been burned by not building a robust enough platform on day 1](https://s3.amazonaws.com/startupcompass-public/StartupGenomeReport2_Why_Startups_Fail_v2.pdf). 38 | 39 | 40 | ### A Startup Pivot 41 | 42 | Around the middle of my tenure at Packback, we began a "pivot." Our textbook rental platform wasn't picking up traction like we had hoped, so one of our founders came up with a new idea for a product that would eventually become Packback's primary focus. 43 | 44 | At the time, however, we didn't know that this new concept would become our biggest revenue generating opportunity, so we didn't start by pulling the engineering team off our existing product. Instead, we cobbled together a stack of services to test our idea before employing our engineering team's time. 45 | 46 | Before bringing any engineers onto the new product, we cobbled together some off-the-shelf services and used a little elbow grease to support around 100 users. [Our first tech "stack" was completely devoid of custom code](https://blog.codeship.com/incremental-software-development-with-php-microservices/), and it had all the basic features that are still present in Packback's Question and Answer platform today. 47 | 48 | The product had to do three basic things: 49 | 50 | - Users had to be able to log in and post questions and answers (think Quora, but for a single classroom). 51 | - Professors wanted a report outlining their students' participation on the platform (eg: number of questions asked and answered) in order to tell who was engaged and who wasn't. 52 | - We wanted to be able to market various paid products to students or remind them to log in and post new content weekly. 53 | 54 | That first bullet point could have been accomplished with just about any open source or cheap forum software. We found one a little more specialized for our use case, and even better it had an API that we could hook into later. 55 | 56 | In order to create reports for professors we had an intern go through and count the number of questions and answers posted by students each week - remember, there were only around 100 users - knowing that while this wouldn't scale, it would help us learn about the things professors wanted in these reports. The ""reports" ended up being Google Sheets that we would then email to professors every week. 57 | 58 | Finally, in order to market to students, we put all users who signed up into Mailchimp email lists so that we could communicate with them periodically. The whole setup cost us less than $100/month, so while we knew it wouldn't scale to millions - or even thousands - of users, it allowed us to test and validate our idea before we went all-in. 59 | 60 | I've written more about the process of cobbling together third party services as an MVP for Packback before, so if you want more details, check out [this post on Codeship's blog](https://blog.codeship.com/incremental-software-development-with-php-microservices/). 61 | 62 | The point is though that Packback was able to build a real product and sell it to real users without investing any real developer time, and I would argue that most software businesses could probably start the same way. While the grand vision that founders have might be impossible without custom code, the first step on a long journey is to get people using your product. You can't do that with just an idea. 63 | 64 | ### Running a Business on Spreadsheets 65 | 66 | Packback isn't the only company that has run a product in Google Sheets or Excel files. 67 | 68 | One of the first companies I worked for in college tested power plants. With millions in revenue, they were a bit out of the early stage startup phase, but they were a young company with a lot of internal innovation. One of the primary software "products" we used was written entirely in Visual Basic for Excel macros. 69 | 70 | While Excel might not be as clean or flashy as a custom UI in an app or website, it can certainly get the job done. Spreadsheets are universal - every business person knows how to open and manipulate an Excel document - and extremely versatile. Even without code you can automate things, build advanced formulas with conditional logic, and decorate your documents with charts, graphs, and images. It's probably the most powerful engine for an MVP in software development today. 71 | 72 | When I first joined The Graide Network, the product was in its very early stages. The code that was there had been built by a low-cost offshore team, so the reliability was low and new features frequently "broke". Since the founders were non-technical, they had to find workarounds for when their MVP fell down, so they simply fell back to spreadsheets and emails. 73 | 74 | This allowed them to generate revenue even before having a fully-baked product, which in turn allowed them to raise money to hire developers and scale up their operations. Many times, founders get stuck focusing on building a perfect product before they sell anything to customers, but this is a dangerous move for companies that should be in the MVP stage. 75 | 76 | ### Overbuilding the MVP 77 | 78 | I've had to opportunity to learn from both the successes and mistakes of many other CTOs in Chicago. While I've heard many stories of overbuilding MVPs, one sticks out in particular. I've changed the names of the company and people involved, but the number of examples like this are amazingly common. 79 | 80 | My friend John was the founder and CTO at a startup that collects data and essentially sells it to customers. This is an increasingly common business model for startups as companies are interested in "big data" but often lack the expertise needed to collect and organize it. John's startup was in this industry, but like many early stage companies, they didn't really know who their customer was. 81 | 82 | That, of course, didn't stop them from raising money on the promise of better data available to everyone. They put together a product designed for the consumer market, gave away most of their data for free, and then sold a premium tier access to their biggest users. Building a product that works well for thousands or millions of users is expensive, and because only a certain percentage will ever become paid users, it can take a long time to reach profitablity. 83 | 84 | Still, investors saw lots of companies making this kind of product, and John's company raised over $2 million promising to capture a percentage of a highly lucrative consumer market. The continued beefing up the product, but sales never came. They made a few sales, but such a laughably small number that it was better to tell investors they were focusing on grabbing free users who they would later upsell rather than admit they didn't have a product anyone wanted to pay for. 85 | 86 | Eventually things came to a head when the company started to run out of money. With less than 3 months of runway, they started letting people go and looking for an emergency round of funding. Raising money when you're cutting jobs is never a good thing because it means investors can cut your valuation in John's case, they even got old investors to give up much of their equity. 87 | 88 | The good thing about going through such desperate times was that the company _had_ to focus on building a real business rather than making a shiny consumer product. They started talking to companies who would license some of their software or pay for access to mass amounts of data, and built a very minimal product to deliver it to them. Many of the consumer-focused product features they built turned out to be wasted effort, but they were able to salvage some of their core data collection and organization services for a new customer who had money and wanted their data. 89 | 90 | It's easy in hindsight to ask why John's company didn't just go for enterprise sales from day one. It's also easy in hindsight to see that they overbuilt a product for a market that had neither the ability or the need for it. That said, half the CTOs I know have made this mistake at some point in their career because as engineers, we have a tendancy to build first and think of the business second. 91 | 92 | Don't make this mistake. Build a truly lean MVP; rely on manual, non-scalable architecture; discover your business. Once you have a model that you know can make money and that the market will pay for it's time to enter the next phase of your early startup's life-cycle. 93 | 94 | -------------------------------------------------------------------------------- /chapters/3-2-mvp-strategies.md: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/karllhughes/portable-cto-book-1/59210b705d8cf7d87e2adc909d1c18aa7843c42a/chapters/3-2-mvp-strategies.md -------------------------------------------------------------------------------- /chapters/3-3-product-workflow.md: -------------------------------------------------------------------------------- 1 | # 1. Agile in a Nutshell 2 | 3 | One of the most popular organizational frameworks for building software today is Agile. Its tenants of rapid development cycles and iterative changes are especially compelling for startups who don't know exactly what their product needs to be and don't have the resources to build everything they can imagine. Every startup I've been at generated 10 to 100 times as many ideas as they could execute, so the real challenge for product leaders is to prioritize these new developments. 4 | 5 | I'm not an expert in Agile, but you don't have to be in order to lead a team of engineers or product developers either. As your organization grows, it will benefit you to either learn more about product development methodologies or hire people who do, but it's helpful if you can at least hold a conversation about Agile and maybe use some of its practices in your early development process. In a later chapter I'll give you a couple product development frameworks that have worked well for myself and others, but I would encourage you to tweak your process as often as you need to. 6 | 7 | ## What is Agile? 8 | 9 | When people first started building software in a corporate setting, the experience was wildly different than it is today. Legendary software book, [The Mythical Man-Month](http://amzn.to/2nCT4dj) talks about writing reams of documentation, waiting hours or days for code to compile, and programming via hand-written or typed instructions. In addition to the challenges engineers faced in constructing and compiling their code, the mediums they had available to distribute it were much slower than they are today. People relied on physical tapes, disks, or drives to send software to customers, so upgrading wasn't a trivial task. 10 | 11 | Naturally, the only way to release software with these technical limitations in place was with large-scale, thoroughly-tested releases. This method of completing a large number of features and bug fixes before a distant release date (usually 3-12 months away) is known as the "waterfall" method, and until software updates became more trivial thanks to the internet, it was pretty much the way all commercial software was built. 12 | 13 | As the first dotcom bubble burst in the early 2000s, a wave of overfunded tech companies fell, and software developers started exploring new release cycles and methodologies. Because engineers and managers with varied backgrounds now had the ability to communicate and pass information around more quickly, some of the best ideas started to get used more widely. In 2001, a [group of these software thinkers](http://agilemanifesto.org/history.html) came together and wrote the first "Agile Manifesto." 14 | 15 | Agile itself does not dictate a specific workflow or outline steps to take to release software. The Agile Manifesto is instead a listing of priorities that the software developers who wrote it believed were most important. It has since been adopted by countless companies and spun out dozens of frameworks - some more rigid than others. The Agile Software Development Manifesto reads: (\*1) 16 | 17 | > We are uncovering better ways of developing software by doing it and helping others do it. Through this work, we have come to value: 18 | > 19 | > - _Individuals and interactions_ over processes and tools 20 | > 21 | > - _Working software_ over comprehensive documentation 22 | > 23 | > - _Customer collaboration_ over contract negotiation 24 | > 25 | > - _Responding to change_ over following a plan 26 | > 27 | > That is, while there is value in the items on the right, we value the items on the left more. 28 | 29 | So in theory Agile sounds great, right? But how can you actually use it in the day-to-day operations at your startup? What does it mean to collaborate with customers and respond to change? How can Agile actually help you make a more successful company faster? 30 | 31 | That's where the various Agile methodologies can help you. I won't cover all of them here, but I'll try to offer a brief overview of three of the most common, and hopefully give you enough information that you can start researching them more for yourself. 32 | 33 | 34 | ### Scrum 35 | 36 | Scrum is probably the most commonly used an Agile framework. A lot of people immediately think of Scrum when they hear Agile, but it's not the only way to follow the manifesto as we will see. Still, Scrum can be a great framework for project management, especially in larger projects with more clear beginning and endpoints. 37 | 38 | Scrum uses [ome terminology that's important to understand first. This makes it a little intimidating to outsiders, but it's really not too complicated. I'm not going to try to cover everything involved in Scrum as that's worthy of a book in itself (check out [Essential Scrum](http://amzn.to/1JQvi0X) if you're interested), but I will attempt to give you a quick overview. 39 | 40 | 41 | #### The Sprint Process 42 | 43 | A "sprint" is a set time period (usually between 1 week and 4 weeks) where work will be done. At the beginning of the sprint, you should have well-developed requirements for each feature to be worked on, and at the end you should have working software that meets those requirements and is ready to be released. Along the way, there are a few standard meetings to help facilitate this. 44 | 45 | ##### Sprint Planning Meeting 46 | 47 | To kick off the sprint, everyone with a stake in the product at hand will gather together to hash out the details of what's going to be done during the work phase of the sprint. During this meeting, the Product Owner (described below) will present the most important items to be done - in order - to the team, and work out any details or clarifying points. The Development Team will then estimate each piece of work based on what they now know about it. Planning and estimating work is a huge but important step in the Scrum process, so this meeting [can take between two and eight hours](https://www.mitchlacey.com/intro-to-agile/scrum/sprint-planning-meeting). 48 | 49 | 50 | ##### Daily Scrum 51 | 52 | Typically Scrum teams meet daily in a short scrum or "standup". The purpose of this meeting is to ensure that everyone on the team has the opportunity to hear what their colleagues are working on, and to ensure that anything blocking a team member is resolved. The meeting should be quick - thirty minutes or less - so you shouldn't try to solve problems, but rather assign follow-up meetings to do so. There are many variations of the daily scrum including asynchronous or virtual scrums, but the point is to have a time set aside each day to spread information around the team. 53 | 54 | ##### Sprint Review/Demo 55 | 56 | When the sprint is complete, the development team will hold a demo and review to showcase their work and get signoff before pushing their code live. I believe this is a great time to build trust between the engineering team and the rest of the business, so I've always held demos in a public place where anyone in the company can join. 57 | 58 | ##### Sprint Retrospective 59 | 60 | Finally, after the demo and possibly the release, the whole team will get together for a sprint retrospective. In this meeting, the team reviews any data they have about their throughput or estimates as well as any feelings they have about the sprint. Usually this meeting centers around "What went well?" or "What could we do better?" questions. 61 | 62 | 63 | #### Scrum Team 64 | 65 | Since Agile emphasizes "individuals and interactions" over processes, we should probably talk about the individual roles that make up a Scrum team. 66 | 67 | ##### Product Owner 68 | 69 | The product owner is usually the business team's representative in the Scrum. Ideally they are the actual end user of the product that is being built, but in larger organizations they're more likely a Product Manager of some sort. In startups they might be the CEO or founder. As long as this point person has the power to make decisions about product tradeoffs, they are the right person for this role. 70 | 71 | ##### Development Team 72 | 73 | These are the engineers, designers, testers, and operations people required to develop the product. Since every organization's product is different, the development team can look very different at different companies. The development team is responsible for doing work on cards as they move through the sprint. 74 | 75 | ##### Scrum Master 76 | 77 | Finally, scrum is facilitated by a scrum master. This person is a leader, but not necessarily the technical expert or highest ranking manager. They just need to be able to keep the process moving and ensure that timeboxed meetings stay on topic. 78 | 79 | You could really dig in and make yourself an expert in Scrum, but I don't think that's the best way for you to spend your time. You're more likely to borrow pieces of Scrum that help you depending on where you are in your company's lifetime. As you get larger and more rigid processes become important, consider getting deeper training in Scrum, sending one of your team members to train in it, or hiring a Scrum Master to help you. 80 | 81 | 82 | ### Kanban 83 | 84 | While not mutually exclusive with Scrum, Kanban is another Agile method based on [a Japanese lean manufacturing system](https://leankit.com/learn/kanban/what-is-kanban/). When applied to software development, [Kanban helps visualize work](https://www.themuse.com/advice/an-underrated-way-for-engineering-teams-to-improve-their-workflow) as it flows through steps in a system and limits the amount of work that is in progress at any given time. 85 | 86 | Kanban means "board" in Japanese, so unsurprisingly, the core element of the system's organization is a board. I like [Trello](https://trello.com/) for managing Kanban boards, but you can try other systems or use a real physical board if that works best for your team. 87 | 88 | ### What Kanban Looks Like 89 | 90 | A simple Kanban board might have six columns that show where each piece of work is in the product development cycle. Here's a Kanban board my team might use: (\*2) 91 | 92 | ![](http://i.imgur.com/EyhkfxW.png) 93 | 94 | #### Column 1: Backlog 95 | 96 | The Backlog column should contain a prioritized list of ideas, bugs, or business needs. The card doesn’t have to have a ton of detail yet, but it should have enough information that your team members understand why it’s important. 97 | 98 | #### Column 2: Planning 99 | 100 | In this column, a product manager will fill out a specification for the feature by meeting with business stakeholders, engineers, and designers. When it’s ready, he or she will move it to the “Ready for Engineering” column. 101 | 102 | #### Column 3: Ready for Engineering 103 | 104 | At this stage, all cards should have detailed specifications. While you may still have questions about technical details, the business requirements should be clear. 105 | 106 | #### Column 4: In Progress 107 | 108 | You can move a card over to “In Progress” at any time. This self-driven “pull” system builds a culture of personal accountability and curiosity. 109 | 110 | #### Column 5: Testing 111 | 112 | When you have completed work on the card, move it to “Testing” where another engineer (or someone on the QA team) will pick it up. 113 | 114 | #### Column 6: Deployed 115 | 116 | Another defining feature is that work should be delivered continually to a staging or production environment. This column allows anyone on the team to see what work has been released recently. 117 | 118 | Once your board is set up, your team will use the board to visualize their work in progress and keep up with what's coming next. I've found this kind of transparency - making our Kanban board public to everyone in the company - a very powerful tool for building trust with the business. A lot of people look at engineers as living in a black box; it's really hard for non-technical managers to know how things are going without a visualization tool like Kanban in place. 119 | 120 | ## Finding an Agile Flow That Works 121 | I don't believe there are "right" answers for how products are developed. Some teams use strict agile methods outlined above, some use other methods like [Extreme Programming](http://www.extremeprogramming.org/). Other companies have built their own processes. 122 | 123 | Your job as CTO is to find a product development workflow that works for you, so throughout the rest of this section I'll outline further details for my process, but keep in mind that you may come up with a different system that's better for you. 124 | 125 | Still, I find it helpful to read about others' models before I break off and build my own, so I hope this section will give you a base that lets you create your own winning product development process. 126 | 127 | ----- 128 | \*1 ©Agile Manifesto Copyright 2001: Kent Beck, Mike Beedle, Arie van Bennekum, Alistair Cockburn, Ward Cunningham, Martin Fowler, James Grenning, Jim Highsmith, Andrew Hunt, Ron Jeffries, Jon Kern, Brian Marick, Robert C. Martin, Steve Mellor, Ken Schwaber, Jeff Sutherland, Dave Thomas. This declaration may be freely copied in any form, but only in its entirety through this notice. 129 | 130 | \*2 ["An Underrated Way for Engineering Teams to Improve Their Workflow" by Karl L. Hughes](https://www.themuse.com/advice/an-underrated-way-for-engineering-teams-to-improve-their-workflow) 131 | -------------------------------------------------------------------------------- /chapters/4-whats-next.md: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/karllhughes/portable-cto-book-1/59210b705d8cf7d87e2adc909d1c18aa7843c42a/chapters/4-whats-next.md -------------------------------------------------------------------------------- /notes.md: -------------------------------------------------------------------------------- 1 | # Outline 2 | 3 | ## [Introduction](chapters/0-introduction.md): 4 | *Need to write* 5 | 6 | - Who is this book's intended audience? 7 | - Early stage startup engineers and product developers 8 | - What are early stage startups? (briefly) 9 | - Small (possibly high growth potential) companies with < 10 employees, product team of 1-5. 10 | - Who is the book's author? 11 | - Led early stage startup product development and software engineering teams 12 | 13 | 14 | ## Part 1: An Introduction to Startups 15 | 16 | ### [What is an early stage startup?](chapters/1-1-what-is-startup.md) 17 | *Need to write* 18 | 19 | - Small, technology-enabled businesses 20 | - They are usually: 21 | - Discovering product-market fit (ie: figuring out how to make money) 22 | - Hoping to use technology to automate or replace human capital 23 | - Raising money from investors or self-funded by founders 24 | - Not profitable 25 | - Solving a problem in an innovative way (eg: Uber) or creating an entirely new market (eg: Facebook) 26 | - Most will fail 27 | - How is it different from small business? 28 | - Why do people want to join/start/work at them? 29 | - Idealistic 30 | - Solving big problems 31 | - Lack of bureaucracy 32 | - Desperation 33 | - Highly romanticised 34 | - A lot of romance that is unraveling 35 | - TV Show "silicon valley" 36 | - Dan Lyons' startup bubble 37 | 38 | ### [The Startup Myth](chapters/1-2-myths.md) 39 | *Need to edit* 40 | 41 | ### [Your Role](chapters/1-3-role.md) 42 | *Need to edit* 43 | 44 | 45 | ## Part 2: An Effective Startup Employee 46 | "efficiency is doing things, effectiveness is getting the right things done" - Peter Drucker 47 | 48 | ### [Defining Success](chapters/2-1-defining-success.md) 49 | *Need to edit* 50 | 51 | ### [Finding Balance](chapters/2-2-balance.md) 52 | *Need to edit* 53 | 54 | ### [Work Habits](chapters/2-3-work-habits.md) 55 | *Need to edit* 56 | 57 | ### [Networking](chapters/2-4-networking.md) 58 | *Need to edit* 59 | 60 | 61 | ## Part 3: Building an MVP 62 | 63 | ### [The Minimum Viable Product](chapters/3-1-defining-mvp.md) 64 | *Need to write* 65 | 66 | - What does this mean? What is the goal of an MVP? When does a company need one, and when do they need something "better"? When will we "outgrow" the MVP? 67 | - https://www.karllhughes.com/posts/when-to-launch 68 | - Figuring out the most bare bones version of your product 69 | - "Make it work. Make it right. Make it fast" - http://wiki.c2.com/?MakeItWorkMakeItRightMakeItFast 70 | 71 | ### [Strategies for Building an MVP](chapters/3-2-mvp-strategies.md) 72 | *Need to write* 73 | 74 | (from least to most work) 75 | 76 | - Fake It 77 | - Buffer's story: https://blog.bufferapp.com/idea-to-paying-customers-in-7-weeks-how-we-did-it 78 | - Cobble Together Third Party Services 79 | - https://www.karllhughes.com/posts/creating-a-tech-startup-without-a-developer 80 | - Hire Someone Else to Write Code 81 | - https://www.karllhughes.com/posts/risk-of-offshore-outsourcing 82 | - Write Code 83 | - Choosing tools and technologies 84 | - Use well-established, tried and true tech that you know 85 | - You are not google/amazon/linkedin: https://getpocket.com/a/read/1774906855 86 | - Pick a language everybody on the team knows well 87 | - Decouple things as much as is reasonable 88 | - Don't overcomplicate things until you have to 89 | - "Often complexity is generated when there is no willingness to recognized that a non fundamental goal of a project is accounting for a very large amount of design complexity, or is making another more important goal very hard to reach, because there is a design tension among a fundamental feature and a non fundamental one." - http://antirez.com/news/112 90 | - Architecture 91 | - Decouple things 92 | - When in doubt, choose the simplest path, you can make it more complex later 93 | - "Architecture is expensive, especially when a new domain is being explored. Getting the system right seems like a pointless luxury once the system is limping well enough to ship. An investment in architecture usually does not pay off immediately. Indeed, if architectural concerns delay a product’s market entry for too long, then long-term concerns may be moot. Who benefits from an investment in architecture, and when is a return on this investment seen? Money spent on a quick-and-dirty project that allows an immediate entry into the market may be better spent than money spent on elaborate, speculative architectural fishing expedition. It’s hard to recover the value of your architectural assets if you’ve long since gone bankrupt." - Big Ball of Mud, http://www.laputan.org/mud/mud.html 94 | - "focus first on features and functionality, then focus on architecture and performance." - Big Ball of Mud, http://www.laputan.org/mud/mud.html 95 | 96 | ### [A Product Development Workflow](chapters/3-3-product-workflow.md) 97 | *Need to write* 98 | 99 | - https://www.karllhughes.com/posts/prioritization-relative 100 | - What's the point? 101 | - Organization 102 | - Transparency: shows everyone what we're working on, what is prioritized, what the tradeoffs are if we switch, etc 103 | - So you can answer the question when someone asks 104 | - Planning and development cycle 105 | - Business goals meeting 1x per quarter (more often if needed) 106 | - Planning meeting every week 107 | - Demo/release every week 108 | - Iteration 109 | - Plan for change, flexibility 110 | - Try new processes 111 | - Maintain reasonable expectations 112 | - Ask "why" to everything. 113 | 114 | 115 | ## Part 4: [What Happens Next?](chapters/4-whats-next.md) 116 | - What's next? 117 | - Fundraising and/or organic growth 118 | - Hiring, management 119 | - What if we do _too_ well? 120 | - Premature scaling is worse than hiccups because you have too many customers 121 | - Prepare for your role to change 122 | -------------------------------------------------------------------------------- /readme.md: -------------------------------------------------------------------------------- 1 | # Software Engineering at Early Stage Startups 2 | 3 | The goal of this text is to provide engineers and product developers with insight into what it's like working for an early stage startup (fewer than 10 employees, typically just 1-3 engineers), and a foundation of knowledge that they can use to help them succeed in this role. The advice comes from my personal experience building small engineering teams at seed-funded technology companies, being the sole engineer at a couple of startups, and from countless conversations with peers and mentors in similar roles. 4 | 5 | Each section has several chapters roughly the length of a typical blog post. This is an early draft, but I'd eventually like to offer it in book form, so if you're interested, watch or star this repository and I'll keep you updated on my progress. Enjoy! 6 | 7 | 8 | ## Index 9 | 10 | - Coming soon! 11 | 12 | ## Acknowledgements 13 | 14 | Coming soon! 15 | 16 | ## Copyright 17 | 18 | This repository and all content within it is subject to copyright and not to be redistributed without the consent of the author. If you want to use or distribute this document, contact me and we can discuss it. 19 | 20 | > © 2017 Karl Hughes 21 | --------------------------------------------------------------------------------