Joe Conley Tagged cto Random thoughts on technology, books, golf, and everything else that interests me Orwell's Rules for Writing (Software) <p>I’m in the middle of reading <a href=";from_search=true&amp;qid=O3MVwYzvHh&amp;rank=1">Churchill and Orwell: A Fight for Freedom</a> and so far really enjoying the parallels drawn between two of history’s most important figures. Both had military experiences which informed their worldviews, both suffered serious career setbacks, and both keenly saw the threat of totalitarianism for what it was and worked tirelessly to prevent its spread.</p> <p>About midway through the book the author enumerates Orwell’s six rules for writing. Examples follow of Churchill having similar thoughts on the brevity, economics, and power of language. So I thought I’d help translate these ideas for any software engineer who might care to listen:</p> <h2 id="1-never-use-a-metaphor-simile-or-other-figure-of-speech-which-you-are-used-to-seeing-in-print">1. Never use a metaphor, simile, or other figure of speech which you are used to seeing in print.</h2> <p>Never use common variable names like <code class="language-plaintext highlighter-rouge">data</code>. That’s not very meaningful, all of this stuff is data! Metaphors and simile don’t tend to be useful unless the ideas are truly core to your abstraction.</p> <h2 id="2-never-use-a-long-word-where-a-short-one-will-do">2. Never use a long word where a short one will do.</h2> <p>Be thoughtful when you name things. Variables, functions, and classes should have the shortest and most meaningful names possible. You’re building a mental world from scratch, and the language you choose defines how everyone else will think.</p> <p>Conversely, unless your indexing over a list, single-letter variables are probably too short. Seeing variables <code class="language-plaintext highlighter-rouge">a</code> through <code class="language-plaintext highlighter-rouge">z</code> littered about code without any context or meaning is plain mean. In my early days of engineering, I heard stories about a paranoid contractor who <strong>intentionally</strong> used obscure naming to make his code impossible to read, thus making him “indispensable”. Fool of a Took! It didn’t work, and I think both Orwell and Churchill would agree there’s a special rung in Hell reserved both <a href="">for people who waste good scotch</a> and engineers who use language to such evil ends.</p> <h2 id="3-if-it-is-possible-to-cut-a-word-out-always-cut-it-out">3. If it is possible to cut a word out, always cut it out.</h2> <p>Prefer functional methods and languages where possible, i.e. choose Scala over Java. This can dramatically reduce lines of code, and help you think at a higher level of abstraction that is generally a positive trait for folks who live and create worlds of abstraction most of the day. Yes imperative code might <em>seem</em> easier to write but if you have to do anything at scale you need tools like this in your toolbelt.</p> <h2 id="4-never-use-the-passive-where-you-can-use-the-active">4. Never use the passive where you can use the active.</h2> <p>Have clear separations of concerns in how you architect systems. If a single method does a dozen different tasks, refactor it. This empowers your objects to have clear and distinct jobs and focus on doing them well. This allows to build high-performing systems at scale if you can reliably compose modules that do what they’re supposed to do.</p> <h2 id="5-never-use-a-foreign-phrase-a-scientific-word-or-a-jargon-word-if-you-can-think-of-an-everyday-english-equivalent">5. Never use a foreign phrase, a scientific word, or a jargon word if you can think of an everyday English equivalent.</h2> <p>When you talk to the business folks, speak in simple terms. Trust me, they know you’re smart, you don’t need to show off. Speaking in plain English helps you show that you’re more than a code monkey, and helps them learn more about software and feel empowered about the product.</p> <h2 id="6-break-any-of-these-rules-sooner-than-say-anything-outright-barbarous">6. Break any of these rules sooner than say anything outright barbarous.</h2> <p>If your startup’s MVP needs to work for tomorrow’s demo, then yes by all means write your imperative for-loops and mutate state to your heart’s content. But be mindful when the exception starts to become the rule.</p> Fri, 26 Feb 2021 00:00:00 +0000 Hire Joel Embiid <p>Startups are a team sport. The players you choose to work with have such an outsized impact on the team (for good or ill) that you really have to have “A” players at every position. But it’s not enough to just say “go hire all-stars”. There’s very specific attributes you need to look for, and that I found this week watching <a href="">Joel Embiid</a> lead the Sixers to a <a href="">gritty overtime win</a>.</p> <p>Joel Embiid is the embodiment of the Sixers philosophy in hiring (AKA drafting) championed by <a href="">Sam Hinkie</a>. He has grown to become a dominant force in the league, consistently ranking at the top in scoring and defense. But when you see him play it’s clear he’s not <em>just</em> your typical all-star. He has a unique blend of skills that serves as a powerful model for early-stage startup hiring.</p> <h2 id="eye-for-talent">Eye for Talent</h2> <table class="image"> <caption align="bottom">Source: <a href=""></a></caption> <tr><td><img src="/assets/embiid_before_after.jpg" alt="Embiid Before and After" /></td></tr> </table> <p>Pictures speak volumes. Beyond his pure physical growth, Embiid is improving his game every year. He’s consistently added different nuances to his offense. This year he’s improved his recognition and <a href="">passing out of double teams</a> (helps to have shooters to pass to, thanks <a href="">Daryl</a>!). This eye towards growth has translated into success on the court.</p> <p>Startup hiring is about finding young talent that you can grow into high performers. It’s probably the trickiest, most challenging, and arguably the most fun aspect of hiring. Like Billy Beane <a href="">trying to find inefficiencies in the market</a>, it’s rewarding to not only identify talent early but help them grow as a significant part of a team trying to build something from nothing.</p> <p>What’s even more poignant about startups is you have to get it right fast! Pro teams get a new draft class every year, and can make up for mistakes like <a href="">this</a> or <a href="">this</a> or even <a href="">this</a> (though I’m still rooting for him). Startups don’t have that luxury. The window for getting the timing right can be so small, and can literally mean life or death, that you have to be brutally efficient when it comes to hiring.</p> <h2 id="wears-many-hats">Wears Many Hats</h2> <p>Here’s the line for Embiid from Tuesday night:</p> <table class="image"> <caption align="bottom">Source: <a href=""></a></caption> <tr><td><img src="/assets/embiid_line.png" alt="Embiid Line" /></td></tr> </table> <p>Excellent scoring, great defense, made all 13 of his free throws, just all-around dominance. This is a big man who can be top 5 in scoring and defense, is strong from the foul line so you can’t resort to <a href="">hack-a-Shaq</a>, and is a good enough shooter to force defenses to respect his presence beyond the arc. At one point on Tuesday he had three guys trying to defend him to no avail, I mean how do you stop a force like that?</p> <p>Point being, it’s very difficult to build startups with specialists. You are going to pivot at some point, and the cost of having high turnover to constantly mix and match narrow puzzle pieces is too inefficient. Seek generalists early, then once you’ve established traction think about more specialized roles. Generalists cost too much you say? Then be generous with the equity upside. Give them real skin in the game, and then give them room to operate.</p> <h2 id="pure-will">Pure Will</h2> <p>The most impressive feat in Tuesday’s win was in the third quarter, Embiid dropped 22 points in 8 minutes. He literally decided to take over the game, got the ball almost every trip down the court, and willed the team to victory. Talent is one thing, but having that pure strength of will is rare and really fun to watch.</p> <p>Find me a team of folks who have that same will to not only push through on execution but also the honest determination to understand what’s true and the vision to navigate, and I’ll bet on them every day of the week. It takes a special strength of character to survive the inevitable ups and downs of startup life.</p> <h2 id="culture-matters">Culture Matters</h2> <p>I’ve been a Philly sports fan all my life, and Embiid has to be near the top as far as local popularity goes. He’s outspoken, goofy, works hard and wants to win. Similar to <a href="">Allen Iverson</a>, he gives it his all, and expects his teammates to do the same.</p> <p>It’s cliche to say that culture matters in startups, but it’s important to note that it starts from the top. Leaders set the culture, either consciously or otherwise. Now more than ever, it’s important to take care of your team, understand their challenges on and off the field, and build an environment that supports them in every way shape and form. Who wouldn’t want to work for a team with a culture of excellence?</p> <h2 id="trust-the-process-and-have-fun">Trust the Process and Have Fun!!!</h2> <p>Lastly and most importantly, we’re on this earth a short while. Let’s have fun and play hard!</p> <iframe width="560" height="315" src="" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture" allowfullscreen=""></iframe> <p><br /></p> Fri, 15 Jan 2021 00:00:00 +0000 What is a CTO? <p>I’ve spent a lot of time thinking about what a CTO is. It’s important to really think through this role as it can have such a huge impact on companies both large and small. You can search the web for “startup CTO vs. big company CTO”, “CTO vs. VP Engineering”, etc., but those debates miss the point. What matters is understanding the function of a CTO in your organization. And I assert that <strong>a CTO is an executive who serves the business through the deployment of technology</strong>.</p> <p>That’s it! The details of implementation will vary widely based on company, industry, and the strengths and weaknesses of the individual CTO. But at its heart, this role requires a leader who has a strong fundamental understanding of technology and how to use it to support a business.</p> <p>What, then, is technology? It’s easy to assume that things just “get better” over time. We’ve emerged from the cave and tilled the earth, dammed the streams, and harnessed the power of the sun as we march towards greater standard of living. However, none of these advancements were inevitable. Progress depends on us inventing the future.</p> <p>This topic is more important than ever. It’s hard to argue that software is <a href="">eating the world</a>, and as a result, <a href="">every company is now becoming software</a>. Technology advancement has accelerated change in every walk of life. Powered by trends of cheap computing power and new techniques to analyze data, this wave of extracting value from data is overhauling every and any domain it gets its hands on.</p> <p>Is this wave of technological progress “good”? Any type of significant change can and will cause issues like job displacement, but I believe that as technology helps automate mundane labor, it should create opportunities for human beings to focus on higher-level, more creative work. This underscores the importance of having strong, thoughtful education for everyone young and old.</p> <p>Given the speed and complexity of these trends, it’s important to have someone who understands technology at a sufficiently deep level (software, hardware, whatever). I’ve found the best CTO’s form strong opinions about their technology choices, yet dispassionately remain open to searching for the best solution. They rely on tried-and-true systems rather than chase what’s trendy. They push hard for excellence, but balance that with sensitivity to solving the customer’s problem in a cost-effective way.</p> <p>It’s also important to note that a CTO is an <strong>executive</strong>. I think the toughest thing for a newly-dubbed CTO to learn is how to scale not just code but <em>an entire organization</em>. As a lead engineer or architect, your choices are mostly constrained to scaling infrastructure or analyzing data. Once that “C” shows up in your title, however, your biggest challenges tend to be people-problems. Which seats on the bus do I fill first? Can I grow this junior resource into a contributor, or do we need to move on? Can I make peace between two warring factions? You’re definitely moving “up the stack” here, and it requires a wholly different skillset than what got you here.</p> <p>Personally, I value the opportunities I’ve had to serve as CTO because I know that I can have a meaningful impact on a company. I know my decisions will have consequences, and I relish the challenge to move the needle where I can. Most of all I enjoy aligning a team towards a common goal. By its nature, technology strives to improve how we live our lives, and to serve as the steward for its application is a privilege.</p> <p>I’ve also been blessed to have found an informal network of mentors who I rely on regularly when facing tough decisions. I’m hoping I can start to <a href="">do the same</a>.</p> <p>At the end of the day, it’s just really cool to helping spearhead the deployment of technology for an organization. I’m a huge Elon Musk fan for a lot of reasons, but his quote about why he went into engineering really spoke to me:</p> <iframe width="700" height="450" src="" frameborder="0" allowfullscreen=""></iframe> <p><br /></p> <p>Just really cool to think about engineering in terms of building new things which enable really smart people to keep making progress and ultimately improve our collective consciousness. It’s inspiring to think we’re all trying to play a part to create a better future. It’s why I pivoted from a pure mathematics career to one grounded in technology. Because it’s “what’s next”</p> <iframe width="700" height="450" src="" frameborder="0" allowfullscreen=""></iframe> <p><br /></p> Tue, 01 Sep 2020 00:00:00 +0000 Shape Up or Ship Out! <p>Have you worked on a software team that consistently shipped high-quality work on-time? I’ve seen companies large and small have plenty of difficult delivering software. Either things break in production, or things don’t ship on time, or worst-case both.</p> <p>And in most cases, the antidote was <strong>supposedly</strong> to “be more agile”. Planning poker, Fiobancci story pointing, backlog grooming, and all of the other well-trodden ceremony should make these issues disappear. And to be fair, I’ve seen these things “work”, but <em>only to a certain extent</em>, and usually over the short-run. I’ve tried them myself with mixed results, and an underlying apprehension I could never put my finger on. Did software engineers pick this profession out of a love of project estimation and ticket management tooling? Does any of this feel like a natural way to treat human beings?</p> <p>And so it is with this undercurrent of dissatisfaction that I recently found <a href="">Shape Up</a> by <a href="">Ryan Singer</a>. It’s a refreshing take on how to craft software. The book is a perfect size to read, and has a great blend of thoughtful ideas paired with practical advice from the trenches of a well-known and successful product company, <a href="">Basecamp</a>.</p> <p>This book hit a lot of notes for me, but the biggest idea was how work is <strong>shaped</strong> and handed off to the development team. Projects aren’t chopped up into tickets, doled out and estimated. The product strategy team defines a project with CLEAR BOUNDARIES and a FIXED TIMELINE, and lets the development team work through the details and manage themselves, with clear checkpoints along the way. This allows developers to use their brains to come up with their own implementation ideas, frees up the product team to stay focused on high-level strategy, and doesn’t require a middle-manager (i.e. Scrum Master) for communication.</p> <p>This is the essence of management that delegates without abdicating responsibility. Shaping creates guardrails to allow a team to grow and experiment without hand-holding, <a href="">trusting but verifying</a> that the project’s thoughtful criteria will be met. I think these ideas would be borderline radical in most companies I’ve seen.</p> <p>Why does any of this matter? Because I believe technology companies can be agents of change. Crafting tools that help automate and streamline rote tasks so human beings can focus more on <strong>human</strong> work should be the ultimate goal of most technology offerings.</p> <p>In that same spirit, how do we as technology leaders ensure that the builders of technology are allowed to do more human work? By giving them more responsibility in an environment where they feel safe. I think the true measure of success for any company is not just revenue growth or user adoption but how did your team grow professionally and personally? Otherwise, <a href="">what’s the point in winning?</a></p> <p>In addition to managing teams, I think the concept of shaping and fixed deadlines helps us manage ourselves too. Rather than keeping an iron-clad todo list, think at a higher level what you’d like to accomplish for a given week or month, make sure you focus on achieving the core “functionality”, and then DELIVER. Keeping a blanket list can trick your brain into thinking all tasks are created equal and MUST be done. Being more thoughtful about time constraints and scope helps to <strong>reframe</strong> and reorient your mind, and start building your shipping muscles.</p> <p>This speaks to another key point that Singer, Clayton Christensen in <a href=";from_srp=true&amp;qid=2DraU5SWZK&amp;rank=1">Competing Against Luck</a> , and even Peter Thiel have all talked about. Namely, a lot of the time the key to solving a problem is how to frame the question. Whether it’s deciding what features to build into a product, how to build out your organization, or how to spend your life, the way we frame the question helps guide us to the answer.</p> <p>Ultimately, finding humane ways to ship software will be an ongoing challenge for leaders and contributors alike. Amid the rise of automated coding tools like <a href="">GPT-3</a>, there will be a need for thoughtful, effective leadership that understands what questions to ask and what tools to build.</p> <p>So Shape Up, or ship out!</p> Wed, 29 Jul 2020 00:00:00 +0000 Ask a CTO Interview with Sarah Herrmann <p>I recently had the pleasure to speak with Sarah Herrmann of Juno Search Partners to kick off her new “Ask a CTO” series. I really enjoyed the chat and I hope my thoughts may be helpful!</p> <p></p> Tue, 31 Mar 2020 00:00:00 +0000 Forbes Technology Council - Encouraging Developer Side Projects <p>I was recently featured in a Forbes article about encouraging developer side projects.</p> <p></p> Fri, 13 Dec 2019 00:00:00 +0000 Working at Buyside <p><em>This post originally appeared on <a href="">Working with Buyside</a></em></p> <p>Our team is growing! I’ve had the distinct pleasure of building out our engineering team over the past year, and as we’re prepping for another round of growth, I thought this was an appropriate time to reflect on what our culture is like. Why do we enjoy working at Buyside? What makes us tick? I asked my team to reflect on that, and I’ve summed up the main points here so that prospective hires can get a good sense of why they might want to join Buyside.</p> <h2 id="autonomy">Autonomy</h2> <p>This was the most common theme by far. Our team is well-distributed geographically, from Pennsylvania to Nevada to Costa Rica, and we pride ourselves in creating an effective environment conducive to remote work. We keep meetings and overhead to a minimum. We subscribe to the adage of hiring smart people to tell us how to do things, and not dictate to them. We encourage healthy debate, and expect team members to take ownership of their work from inception to completion. This allows all of our team members to grow while serving the needs of our clients.</p> <h2 id="productivity">Productivity</h2> <p>Similar to the above, we want to create an environment that optimizes productivity. This isn’t treating our team as cogs in a machine, but rather understanding that when we hire smart and motivated people, they tend to be happiest when they are feeling productive. We provide top-of-the-line machines. We <em>try</em> to minimize context-switching as much as possible (some days are better than others). As most of us have families and kids, we respect work-life balance and allow for flexible schedules. We know this approach is a win-win for both our team and our company.</p> <h2 id="value">Value</h2> <p>Despite our recent growth, we still maintain the scrappiness and energy of a startup. We expect everyone to make meaningful contributions to the direction of the company, and I as a tech leader take great pains to ensure the team is constantly aware of the impact of their work. One advantage we’ll always have over the bigger tech companies we compete with over talent is offering the opportunity to be part of a special team that’s offering real tangible value to their clients.</p> <p>And we’re just getting started! I’m really excited about the work we’re doing now and in the short-term, as the next year promises to be one of unprecedented growth for Buyside. If you think you might be a good fit for our team, please check out our <a href="">Careers</a> page for our current openings. Thanks!</p> Thu, 14 Nov 2019 00:00:00 +0000 Managing Distributed Teams <p>I was recently featured in an article discussing how CTO’s manage remote teams. It’s certainly a non-trivial task, but an increasingly relevant one as software teams become more and more geographically distributed. I think this a great trend, as your potential resource pool becomes much wider once you look beyond your backyard.</p> <p>I’ve certainly been blessed to have found such strong talent to work with at Buyside, both locally and remotely, and our company is the better for it.</p> <p>Enjoy!</p> <p><a href="" target="_blank"></a></p> Fri, 01 Nov 2019 00:00:00 +0000 Leadership Aboard the Santa Fe <p>What is leadership? It’s certainly a fancy term. It adorns countless corporate walls paired with some inspirational message or image. It appears as a common requirement for most management-level job applications. It can even inspire folks to come together in an almost cult-like fashion:</p> <iframe width="700" height="450" src="" frameborder="0" allowfullscreen=""></iframe> <p><br /></p> <p>But <strong>defining</strong> leadership can be tricky. We can use words like humility, decision-making, servant to try to arrive at a definition, but that’s boring and often incomplete.</p> <p><img src="" alt="" /></p> <h2 id="leader-follower-to-leader-leader">Leader-Follower to Leader-Leader</h2> <p>I recently read L. David Marquet’s <em>Turn This Ship Around!</em>, and came across a truly great example of what it means to be a leader. In short, leadership is creating an environment that helps your subordinates grow into becoming leaders themselves. Marquet did this in a seemingly unlikely setting: aboard a submarine in the U.S. Navy.</p> <h2 id="how">How?</h2> <p>Here are my main takeaways from the book to how to shift to this new paradigm:</p> <h3 id="create-an-environment-of-ownership">Create an environment of ownership</h3> <p>It’s important that the environment is tailored to allow reports to make decisions and think on their own, but be accountable for their decisions. Marquet encouraged this by requiring his junior officers to recommend what actions to take. Instead of Marquet giving orders, he’d have his reports make decisions, having them say “I intend to” before acting. e.g. “I intend to take the ship up to periscope depth…”, while Marquet would give simple confirmation. Even little things like language can help encourage passive officers to think independently.</p> <h3 id="delegate-but-dont-abdicate">Delegate but don’t abdicate</h3> <p>Marquet tried out a Leader-Leader experiment on the U.S.S. Will Rogers without much thought into how it was implemented. This led to an oversight in readiness, a failed inspection, and a quick transfer to a Soviet outpost where he could spend time reflecting on just how poorly his first efforts had been. Simply delegating tasks without thought to how they’d be carried out is a recipe for failure.</p> <p>Once he got another shot aboard the U.S.S. Santa Fe, he focused more on developing the level of competency of his officers. He resisted the urge to dictate solutions to problems, but instead gave his folks latitude to work through issues. As Marquet succinctly put it, “Don’t brief, certify”.</p> <h3 id="communicate-vision-without-dictating">Communicate vision without dictating</h3> <p>Communication is paramount. Especially for significant changes that are new or uncomfortable, you can never communicate too much what your vision is.</p> <h2 id="applied-to-tech">Applied to Tech</h2> <p>I’ve certainly struggled with delegating, especially on a small team where there’s plenty of work to go around and never enough bodies to do the work. I think I’ve gotten better at communicating context and the necessary details of a particular issue or task, however I know sometimes I’ll lead with my proposed solution without allowing my reports to come up with their own design.</p> <p>But overall the ideas in this book have helped me start to think more about how I operate and how I can do a better job of creating an environment that creates great leaders.</p> <h2 id="results">Results</h2> <p>Marquet’s work resulted in the Santa Fe earning a record number of awards in both excellence and most improved. Furthermore, Marquet’s officers were promoted at unusually high rates to lead their own ships, and applied most of what they learned aboard the Santa Fe to their own ships.</p> <p>In business, it’s easy to get caught up in optimizing specific metrics, growing profits or increasing market share. But doesn’t that all pale in comparison to helping others grow? To inspiring others to build a brighter future? In that way, leadership can be boiled down to priorities. How you choose to spend your time, what you choose to value above all, and how you choose to impart those beliefs to others.</p> <p>How do you define leadership?</p> Thu, 03 Oct 2019 00:00:00 +0000 RVNTV Interview <p>I did an interview recently on Tech Talks, a local tech show hosted by Michael Bertoni. I talk a bit about my time at Buyside, how I’ve built my teams, and what I’m looking for next in ML/AI trends. Enjoy!</p> <p><a href=""></a></p> Tue, 24 Sep 2019 00:00:00 +0000 Forbes Technology Council - Troubleshooting Code Malfunctions <p>I was recently featured in a Forbes article about troubleshooting code. Enjoy!</p> <p></p> Thu, 18 Jul 2019 00:00:00 +0000