tag:scottcarleton.com,2014:/feedScott Carleton2018-09-12T11:07:37-07:00Scott Carletonhttp://scottcarleton.comSvbtle.comtag:scottcarleton.com,2014:Post/principles-great-work-great-learning-part-32018-09-12T11:07:37-07:002018-09-12T11:07:37-07:00Principles: Great Work ∞ Great Learning Part 3<p><strong>Note:</strong><br>
This is the third post of a multipart series about the relationship of work and learning, and how it goes together for individuals and for companies. I recommend <a href="http://scottcarleton.com/principles-great-work-is-great-learning">starting at the beginning.</a></p>
<h2 id="act-2-the-lab-aka-alright-ill-just-do-it-myse_2">Act 2: The Lab aka “Alright. I’ll just do it myself” <a class="head_anchor" href="#act-2-the-lab-aka-alright-ill-just-do-it-myse_2">#</a>
</h2>
<p>I left BigCo because I wasn’t learning as fast as I wanted to. I was impatient and believed there had to be a better way. Starting my own company wasn’t my first choice. I explored less risky options. MBA program, early startup employee, VC associate. But I ran into a common blocker. These options were all <a href="https://steveblank.com/2018/04/11/why-entrepreneurs-start-companies-rather-than-join-them/">underestimating my value</a>. I (thought) I could do better on my own.</p>
<p>I’m grateful for my arrogance because it turns out that starting your own company is the equivalent of an educational firehose. My rate of learning was completely within my control. How fast can you learn? Well, how many endeavors can you juggle at one time? Every step forward in creation was its own fount of knowledge. Legal, Accounting, Engineering, Product, Marketing, Sales, Operations, Hiring, Firing, Team Building. You must wear every hat and become competent enough in each to (hopefully) hire someone better.</p>
<p>After a year I realized I accomplished my initial goal. I was learning a lot - faster than I ever had before. I loved it. I was maximizing my learning but the clock was ticking. I needed a new goal, focused on keeping this going. How do we become successful so that we all can keep learning - to continue doing what we love?</p>
<p>This would all go away if we didn’t figure out a method to sustain it. But, I didn’t want that method to sacrifice my own learning rate.</p>
<p>I was fortunate to learn about <a href="http://theleanstartup.com/principles">Lean Startup principles</a>. It clicked. Learning about your customers and eliminating business risks incrementally was perfectly aligned with the work we needed to do to become successful. I became rabidly focused on validated learning to overcome obstacles. </p>
<p>Incorporating these ideas, a high functioning product development team emerged. Business success required fast iterations. Hypothesizing, executing, reflecting and then repeat. Work and learning coexisted harmoniously with a positive feedback loop. And, the best part was it was fun and addictive!</p>
<p>A new axiom was beginning to form in my mind:</p>
<blockquote class="short">
<p>If you can construct an environment where the team is maximizing their learning then it will maximize business benefits as well</p>
</blockquote>
<p>Benefits of this mindset didn’t stop at product development. As this work and learning relationship evolved, we attracted talent who were interested in maximizing their personal work and learning. Since our environment required learning in order to succeed, the highest potential people performed the best and contributed the most to our learning culture. I had required myself to get up to speed on subjects I had never encountered before and because of this, I found a deep belief that others could as well. We focused on growing our people quickly to take on ever greater challenges in the competitive market. Business output and individual output were linked and yielded a strong desire to continue working hard.</p>
<p>The culture emerged to reflect its people and their values. Collaboration was the default in order to get better ideas into the foreground and learn from them. These collaborations yielded better learning, which further feeds the learning addiction and also created real human bonds between everyone in the office.</p>
<p>Through this process, and a lot of reflection, I learned that a team can have a happy marriage of individual and business incentives, where each team member’s learning is a win-win.. The positive link between work and learning was now cemented in my mind.</p>
<p>Despite our talent and virtuous alignment of work and learning. We did not succeed in finding a way to sustain it. One big question remained for me. Could this work at scale? For that, I needed to jump back into larger teams to learn yet again….</p>
<p><em>To be continued</em></p>
tag:scottcarleton.com,2014:Post/principles-great-work-great-learning-act-12018-07-08T16:01:39-07:002018-07-08T16:01:39-07:00Principles: Great Work ∞ Great Learning Part 2<p><strong>Note:</strong><br>
This is the second post of a multipart series about the relationship of work and learning and how it goes together for individuals and for companies. I recommend <a href="http://scottcarleton.com/principles-great-work-is-great-learning">starting at the beginning.</a></p>
<h2 id="act-1-big-co_2">Act 1: Big Co <a class="head_anchor" href="#act-1-big-co_2">#</a>
</h2>
<p>Entering the working world with a mental model based on maximizing my own learning, I was enamored by my initial experience in a large engineering company. There was so much to learn and absorb! However, this faded as I got up to speed and quickly, I became frustrated. I loved the initial steep learning curve. Once it leveled off, the work didn’t continue to evolve at a high rate. I wanted to keep sprinting up the hill but found that it had plateaued.</p>
<p>Why was this daily rate of growth so slow? Companies need to innovate and evolve to be competitive. To my dismay, I found my company’s ability to innovate was not based on the desire or ability of it’s most earnest employees to learn. Shouldn’t these employees be encouraged to drive innovation and evolve? Apparently not. </p>
<p>Reflecting now, I see that in many larger companies, the rate of learning is limited by the organization’s systematic rate – which is set by the company’s lowest common denominator (or at best, average) and not by its most talented people. </p>
<p>These large companies have become a series of 3-legged races. You have to work together, but you are also dependent on whomever you are tied to. Just like a chain is only as strong as its weakest link, an interconnected engine will only operate as quickly as it’s slowest sub-component.</p>
<p>How does this happen? Does it have to be like this? </p>
<p>As a company grows, speed and innovation become secondary to consistency. Consistency enables strategic decision making and efficient resource allocation. Consistency also makes the future more predictable, which creates market reliability. </p>
<p>The least resistant path to consistency is scaling “what we know already works,” which means replicating successful processes. As process begins to dominate, individual learning suffers. Learning is an unnecessary side product, left behind for more efficiency. An increase in process reduces the need for an employee to learn on their own.</p>
<p>The result of this is that BigCos get reliable output and employees get a reliable job with a set rate of personal growth<sup id="fnref1"><a href="#fn1">1</a></sup>. Bureaucracy, the collection and centralization of process, increases and begins to direct the culture<sup id="fnref2"><a href="#fn2">2</a></sup>. </p>
<p>The culture might not be entirely dysfunctional, but it’s not a hotbed of collaboration either because the overriding system discourages risk taking. For an employee, the culture will fit if it aligns with her values, but if her primary goal is learning she’ll become frustrated by spending her time learning BigCo’s particular flavor of process and bureaucracy; not fundamental truths. Sometimes policy/process appear to defy logic, and an employee feels helpless to fix it. “That’s just the way it is around here” you might hear - which only reinforces the lack of autonomy for individuals and demoralizes those who want to learn.</p>
<p>You can see why BigCos may not be able to retain the most talented candidates who are optimizing for their personal learning and growth.</p>
<p>I began to fear a future where I would be a cog in this inefficient machine indefinitely. I was struggling to find faster paths of learning within the system, to no avail.</p>
<p>The moment I realized I wasn’t learning as fast as I wanted to, I started looking towards the door. I had no idea what I wanted to do next. Even so, I took the plunge, trusting that I’d figure out something just like my <em>entrepreneurship</em> professor had…</p>
<p><em>To be continued</em></p>
<div class="footnotes">
<hr>
<ol>
<li id="fn1">
<p>Dictated by the initial learning curve and then the rate of learning dictated by the limiting sub-component of their immediate organization. <a href="#fnref1">↩</a></p>
</li>
<li id="fn2">
<p>Culture is what is perceived to be rewarded and punished. At BigCo, following process is perceived to be rewarded and vice-versa. <a href="#fnref2">↩</a></p>
</li>
</ol>
</div>
tag:scottcarleton.com,2014:Post/principles-great-work-is-great-learning2018-06-30T10:10:48-07:002018-06-30T10:10:48-07:00Principles: Great Work ∞ Great Learning<p><strong>Note:</strong><br>
This is the first post of a multipart series about the relationship of work and learning and how it goes together for individuals and for companies.</p>
<h2 id="inception_2">Inception <a class="head_anchor" href="#inception_2">#</a>
</h2>
<p>The concept was initially seeded in my mind over a decade ago by a guest lecturer in my university entrepreneurship class. “My first job out of college was with the Ford motor company” he said. “I had great pay, a solid job for life - if I stayed around for the next 40 years I could have had a pension and a nice gold watch. However, after 4 years I left.”</p>
<p>“You go and work for someone, what’s the exchange? You exchange your time and sweat and they pay you money. Is that a fair trade? No. Here’s what’s missing. Your time can never be recovered. However, money can always be created. You’re giving your most precious asset in return for something ephemeral. What makes it all worth it?“</p>
<p>Nobody responded.</p>
<p>“You get to learn. When you put your time and sweat in, you are compensated with money - but what really balances out the equation is the education you receive as a part of that work. The moment I stopped learning at Ford was the day I quit.”</p>
<p>Until this point, I imagined that I’d always be ‘working to live’ - working to make ends meet while I pursued what I really wanted to do in my remaining time. But, what I wanted to do in my remaining time was to <em>learn</em>, to invest in myself, to improve across a variety of dimensions. My paradigm shifted. Work wasn’t just about money. Work could provide a scaffold for growth. Now I understood how work itself could be fulfilling. </p>
<p>Going forward, I decided to optimize my work for learning. ‘Am I learning?’ became a guiding question in my life choices. A question that answered ‘no’ a few years later when I quit my first job.</p>
<p>Continued in <a href="http://scottcarleton.com/principles-great-work-great-learning-act-1">Part 2</a></p>
tag:scottcarleton.com,2014:Post/startupcto-optimize-your-learning-velocity2018-03-02T08:36:53-08:002018-03-02T08:36:53-08:00StartupCTO: Optimize your Learning Velocity<p>Here’s a <a href="https://startupcto.io/podcast/0-42-optimize-your-learning-velocity-w-scott-carleton-andela/">podcast interview</a> I did with the great guys over at <a href="https://startupcto.io/">StartupCTO.io</a>.</p>
<p>Here are some of their favorite quotes:</p>
<ul>
<li>You hear a lot that “it’s all about the people,” but you don’t really get it until it kicks you in the shins.</li>
<li>I think a lot about communication through a company in the context of dynamic systems and controls. You can have an input of information where someone’s unaligned or there’s some dissonance, and you’re not going to feel the full impact of that until it works it’s way through the organization.</li>
<li>In the early days, I felt like I needed the “best” engineers. That came out as needing Stanford Grads. But what I realized very quickly was that they had very different expectations and needs. I couldn’t provide for them the right kinds of challenges because we were still hunting for product market fit.</li>
<li>I’ve found that in hiring I should look for “potential” and not “pedigree”.</li>
<li>We created a culture of really customer focused engineers. Engineers that would really own their parts of the product. They <em>really</em> care about it’s usability.</li>
<li>Friction rises in communication when information doesn’t have a place to settle.</li>
<li>Chat is a tool. I’m sold on it. It’s a tool that is necessary but not sufficient. You need the tool to be able to create the behavior you want, but you need a cultural change or a behavior/belief change to use the tool effectively.</li>
<li>Chat allows us an always on meeting in its worst form. At best, it’s an asynchronous tool to keep everyone in sync.</li>
<li>On chat, my top belief is “Get everything into public channels”</li>
<li>The health of an engineering team is: How many issues are raised and resolved, and how fast is that iteration?</li>
<li>Finding out how to have the right focus for a conversation in a chat channel is important.</li>
<li>When I first started doing 1:1s, I totally didn’t want to do it. I’d make up excuses. Every 1:1, there were engineers who would complain and I just wanted to avoid that. But it turns out 1:1s are invaluable because you’ll always discover something important that you don’t know.</li>
<li>If you’re having problems in your organization, a 1:1 is like taking a knife to that problem and sinking it a little deeper.</li>
<li>When I first joined an organization with an existing engineering team, the first 1:1s were very much “clearing out the backlog” — Figuring out the existing problems.</li>
<li>I have a passion for developing people’s potential.</li>
<li>How do we measure someone’s learning velocity – how quickly they’re picking up new skills?</li>
<li>The killer problem with distributed teams right now is white boarding. It’s just <em>so</em> hard to do remotely.</li>
<li>Distributed teams are about trust. How do you get the information you need? How do you communicate outward & upward so that we have trust at all times? We need to know we’re all pushing in the same direction.</li>
<li>Whats really incredible about software development is that the people who are building the applications have a lot more information about the problems they’re solving than you do. You really want most solutions coming from the bottom up.</li>
<li>I like to focus on how I can expose business problems to the team. </li>
<li>Zone of Proximal Development is the Goldilocks Zone for Learning — It isn’t too easy, it’s not too hard.</li>
<li>Customer relationships and ownership of your work are really important for engineers.</li>
<li>The height of collaboration is really direct feedback.</li>
<li>The most generous thing you can do is give really good critical feedback.</li>
</ul>
tag:scottcarleton.com,2014:Post/my-mission2018-02-27T15:02:53-08:002018-02-27T15:02:53-08:00My Mission<p>Lately I’ve been reconnecting with the NYC tech community. The most common question is, ‘what have you been up to the last few months?’ Although a lot of my time has gone to home improvement (just moved into a new place) and side projects, the bulk of my time has been spent on ‘knowing myself.’ This started due to a strong need for me to better evaluate my past in order to better prepare and handle my future.</p>
<h2 id="why_2">Why? <a class="head_anchor" href="#why_2">#</a>
</h2>
<p>I have a belief that in working with and understanding the world, it comes down to two key variables. The environment and you. These can be difficult to disentangle because we don’t have perfect information about either nor lines to separate the two. However, to better evaluate past and future environments, it helps a lot to know yourself well in order to effectively remove it from the equation. This reminds me of a Sun Tzu quote:</p>
<blockquote class="short">
<p>If you know the enemy and know yourself, you need not fear the result of a hundred battles</p>
</blockquote>
<p>Removing the military strategy bits, my spin on this would be something like</p>
<blockquote class="short">
<p>If you know your environment and know yourself, you have perfect clarity in your effectiveness and happiness. </p>
</blockquote>
<p>From this root, with the goal of becoming a more effective and happier person, I set out on a project to deeply know myself (and figure out the environment part later). The culmination of this has been a personal mission statement. Unlike a company mission statement, mine doesn’t state what I’m doing to change the world. It’s more about how I’d like to interact with the world and remembering what’s most important to me. It’s a formulation of my principles and values and provides a guiding lens on how I (should) approach my life.</p>
<p>I’m planning on explaining the process in depth later but for now, the important aspect of my mission is that it’s built upon a few key principles. These are learnings I’ve gained throughout my life and tend to be things that can neither be proven nor disproven; they are simply beliefs I’ve gained. I’ve taken a lot of time to write out and distill my principles over the last few months and soon I’m excited to share some of them.</p>
<p>But first, without further ado, here’s my personal mission:</p>
<blockquote>
<ul>
<li>To understand the world via direct interaction and creation. </li>
<li>To create abundance which further spurs more creation.<br>
</li>
<li>To take initiative without fearing the consequences and empower others in their pursuit of the same. </li>
<li>To define my own path and be proactive instead of reactive. </li>
<li>To impact the world by improving it with iteration. </li>
<li>To disregard externalities and focus on making each iteration easier. </li>
</ul>
</blockquote>
<p>I’m planning on writing a bit about each principle that underlies this mission. Here’s the first one I’m working on a post for</p>
<ul>
<li><a href="http://scottcarleton.com/principles-great-work-is-great-learning">Great Work ∞ Great Learning</a></li>
</ul>
tag:scottcarleton.com,2014:Post/developing-people-in-a-distributed-environment2018-01-17T14:34:20-08:002018-01-17T14:34:20-08:00Developing People in a Distributed Environment<p>Originally posted on <a href="https://www.linkedin.com/pulse/developing-people-distributed-environment-scott-carleton">LinkedIn</a> on May 1st, 2017<br>
<a href="https://svbtleusercontent.com/ctw0ulj0giihba.jpg"><img src="https://svbtleusercontent.com/ctw0ulj0giihba_small.jpg" alt="img5.jpg"></a><br>
Engineers want to believe that distributed relationships can work perfectly; that you can just do your work and not be bothered with the people aspect. That’s false. In a distributed environment, it’s even more critical to form human relationships and prioritize “noise” so that we can all better calibrate the signal.</p>
<h3 id="embrace-the-noise_3">Embrace the Noise <a class="head_anchor" href="#embrace-the-noise_3">#</a>
</h3>
<p>As <a href="http://randsinrepose.com/archives/the-update-the-vent-and-the-disaster/">many have said</a>, one-on-ones are essential. Currently, I have weekly one-on-ones with my direct reports, and bi-weekly ones with all of their direct reports. That face time is so valuable, for pairing, for collaborating and especially for getting to know each other. These one-on-ones are time spent fostering ‘noise’ which is the key for building trust and calibrating the signals in your relationships.</p>
<p>Just like mastering anything, the more you improve the more you’re aware how far you have to go. In my early one-on-ones, I was totally allergic to the notion of talking through progress or team dynamics for a half hour. You think: “Shouldn’t I be building, or strategizing, or blogging, or clarifying our direction?” Or: “They’re just going to complain, and I’d rather avoid that.”</p>
<p>Wrong. Whereas your first inclination in a remote one-on-one may be to run down the list of tasks and blockers, digging into how productive and empowered your direct reports feel is often a better use of your time. </p>
<blockquote class="short">
<p>Not only are one-on-ones absolutely critical for building trust, but they double as an early warning detection system within your organization.</p>
</blockquote>
<p>Not only are one-on-ones absolutely critical for building trust, but they double as an early warning detection system within your organization. As a manager, actively seeking out issues is fundamental – if there’s something you don’t know, you need to race toward it as quickly as possible. If you can become the lightning rod for issues, you become the person who can triage these issues. The earlier you have these signals, the earlier you can move from fire-fighting to fire prevention.</p>
<h3 id="whats-your-vdap_3">What’s your VDAP? <a class="head_anchor" href="#whats-your-vdap_3">#</a>
</h3>
<p>Once you’ve made time and embraced the “noise,” I’m finding it’s important to create a system or protocol where you’re able to get the right signals through all of that noise. “VDAP” — Velocity, Direction, Acceleration, Position — is something we’re trialing <a href="https://andela.com/what-we-do">at Andela</a> to facilitate productive relationships within teams.</p>
<p><strong>Velocity</strong> is meant to gauge an individual or project’s current progress. Do you feel like you or your product is moving well this week? Are you getting things done and overcoming blockers?</p>
<p><strong>Direction</strong> captures a broader understanding of the project and the team’s goals. Do you know where you’re going? Do you know what the goal of the current project is – and how it fits into the company’s goals?</p>
<p><strong>Acceleration</strong> is a measurement of learning and growth. Is this week better than last week? Are you or your team moving more quickly than you were last week?</p>
<p><strong>Position</strong> focuses on the current and future state of not only the project, but more importantly the individual’s role on the team. Are you happy with your progress? Do you like your current role? Do you understand where you’re at, where you want to be, and the difference between the two?</p>
<p><a href="https://svbtleusercontent.com/eqiy6u42ktzwoa.jpg"><img src="https://svbtleusercontent.com/eqiy6u42ktzwoa_small.jpg" alt="img6.jpg"></a></p>
<p>It’s absolutely critical to understand how your team sees and feels about their work. VDAP is a really helpful, concise method to detect boredom, drowning or blockers.</p>
<p>It can be a nice, casual protocol such as “hey, what’s your V-Dap?” with quick responses. Or, you can go in-depth on a project and break down each piece accordingly.</p>
<p>The goal of VDAP is to isolate key signals and burrow down into them to get a regular cadence. It borrows a bit from physics – literally, an object moving through space – as well as agile concepts, mainly Velocity and Direction. At Andela, we prioritize getting people pointed in the right direction and accomplishing things every day, and use small course corrections over time to steer the ship.</p>
<p>Distributed teams benefit from VDAP because it provides a framework for thinking about your work and how to communicate it upwards in a compact format. If you can recognize when a team is getting things done but not moving faster each week, you have a good signal to dive deeper into how to optimize. If they’re getting things done but not sure where they’re heading, it’s a signal to step in and help that team plan out the roadmap.</p>
<blockquote>
<p>The ideas coming from the bottom are good ones — and as a distributed manager, it’s your job to expose the larger business goals and challenges to your team.</p>
</blockquote>
<p>Ultimately, the people building the application and the code have a lot more information about the problem than you do as the manager. The ideas coming from the bottom are good ones — and as a distributed manager, it’s your job to raise them upward. It’s also your job to expose the larger business goals and challenges to your team so that they’re able to think about how to break down those problems. And chances are, their solutions will be much better than what you (the manager) could come up with. To put it simply, they see what you can’t.</p>
<h3 id="the-zone-of-proximal-development_3">The Zone of Proximal Development <a class="head_anchor" href="#the-zone-of-proximal-development_3">#</a>
</h3>
<p>Great work is great learning – if you’re truly delivering, you’re learning constantly. If your VDAP is high, you’re in a position to maximize both output and learning velocity simultaneously. Now we can optimize the process.<br>
<a href="https://svbtleusercontent.com/3guefmxnqtaxca.jpg"><img src="https://svbtleusercontent.com/3guefmxnqtaxca_small.jpg" alt="img7.jpg"></a></p>
<p>The “Zone of Proximal Development,” or “ZPD,” is a place where an individual can level up consistently. It’s that goldilocks zone where whatever you’re working on isn’t too easy, and it’s not too hard – it’s attainable but also challenging enough for you to build. In the same way that smaller pull requests are easier to review and merge, tasks in the right ZPD are easier to level up on.</p>
<p>In order to speed up learning velocity we need two things: a developer’s ZPD and a task’s relative difficulty level for that developer. Neither of these problems are simple. Determining a developer’s ZPD – a moving target – requires a historical record of output and some methodology to determine if a person already ‘knows’ something. Determining a given task’s relative difficulty requires categorizing and understanding it at a granular level, taking a best guess approach and then iterating on it as you collect more data. Thankfully, this leads to a system that improves over time. The more data we collect, the better we can match types of tasks to developers and then improve their learning velocity.</p>
<blockquote class="short">
<p>But what about determining if someone ‘knows’ something? It’s more challenging than it sounds.</p>
</blockquote>
<p>But what about determining if someone ‘knows’ something? It’s more challenging than it sounds. You can’t ask if someone knows something and expect any real accuracy. Universities solve for this by administering tests that ask students to provide an output that’s congruent with the knowledge they’re supposed to have. Engineering interviews tend to fall on the same crutch using whiteboard questions as a proxy. Our methodology is a bit different and it revolves around the latest advancements in learning sciences.</p>
<p>Instead of tests, assessments or whiteboarding, we’re looking to observe behaviors or beliefs to confirm whether an individual has a certain knowledge set. By collecting data points on these behaviors and beliefs that we’ve been observing for each of our developers, every day for the past three years, we can create a probabilistic model to determine confidence in someone’s knowledge. Leveraging this in the future, we will soon be able use machine learning and other AI techniques to give us predictors of current knowledge levels and determine what feedback is necessary at what time to help someone improve.</p>
<p>For instance: If I have a GitHub pull request of JavaScript, I can statically parse that and have a pretty good sense of whether you understand prototypal inheritance – and we can figure out the probability and the accuracy of that. If we determine that you don’t fully grasp the intricacies of prototypal inheritance, then we can look at your past knowledge and how you’ve learned to determine if it’s in your ZPD. If it isn’t, we can identify the gaps, fill them and prepare you better to try and tackle it.</p>
<p>At Andela, we’re building the systems that allow us to understand when a task is in the right ZPD for an engineer. We’re in the early days, but the potential impact for engineering organizations that are able to leverage the learning sciences to develop their individual contributors at scale is massive.</p>
<p>But more on that to come. Stay tuned for next week’s post, where we’ll discuss how to scale efficient, distributed teams across all parts of the organization.</p>
<p>Special thanks to <a href="https://www.linkedin.com/in/christine-magee-60342319/">Christine Magee</a> for her excellent editing and work on this post.</p>
tag:scottcarleton.com,2014:Post/an-engineering-manager-s-guide-to-the-future-of-work2018-01-17T14:12:56-08:002018-01-17T14:12:56-08:00An Engineering Manager’s Guide to the Future of Work<p>Originally posted on <a href="https://www.linkedin.com/pulse/engineering-managers-guide-future-work-scott-carleton">LinkedIn</a> on April 18th, 2017<br>
<a href="https://svbtleusercontent.com/jhon8uomntazcg.jpg"><img src="https://svbtleusercontent.com/jhon8uomntazcg_small.jpg" alt="img1.jpg"></a></p>
<blockquote class="short">
<p>Andela <> Zapier team meeting or Brady Bunch intro?</p>
</blockquote>
<p>Last month, Stack Overflow released its <a href="https://stackoverflow.com/insights/survey/2017">annual Developer Survey</a>, which polled over 64,000 developers across the globe about their favorite technologies, coding habits and work preferences. One of the key highlights was a strong preference for distributed work. A majority of developers (64%) reported working remotely at least one day a month, and 11% reported working remote full-time. Even more telling is that developers ranked “remote options” as a top priority — <a href="https://qz.com/950973/remote-work-for-programmers-the-ultimate-office-perk-is-avoiding-the-office-entirely/">the ultimate office perk</a> — second only to number of vacation days when assessing new job opportunities.</p>
<p>If you believe that <a href="https://www.joelonsoftware.com/2016/12/09/developers-are-writing-the-script-for-the-future/">developers are writing the script for the future</a>, these results would indicate that the next act is going to be remote-first. Factor in the severe <a href="http://www.ciodive.com/news/skills-gap-clear-as-lack-of-software-talent-has-a-direct-revenue-impact/438544/">shortage of U.S. technical talent</a> and <a href="https://www.bloomberg.com/news/articles/2017-04-03/new-h-1b-guidelines-crack-down-on-computer-programmer-jobs">recent restrictive work policies</a> on top of that, and it would appear that the distributed <a href="http://observer.com/2016/03/the-future-of-work-will-be-distributed/">“future of work”</a> might arrive much sooner than anticipated.</p>
<p>Distributed, however, is very hard to do well — it requires a lot of thoughtful strategy, much more than just setting up remote employees on Slack. And if tech companies want to effectively leverage this model, they’ll have to commit 100%. It might result in some growing pains at first, but it will ultimately result in processes and systems that will improve communication and efficiency across the entire organization.</p>
<p>During the last six months as VP of Technology at <a href="https://andela.com/">Andela</a>, I’ve been running a team of nearly 40 people — spread out across New York, Lagos, and Nairobi — who are building out the systems and tools we need <a href="https://andela.com/what-we-do">to make distributed teams excellent and scale</a>. For Andela, that means growing from 500 people to over 100k in less than 10 years.</p>
<p><a href="https://svbtleusercontent.com/el1wwjj1oarsdq.jpg"><img src="https://svbtleusercontent.com/el1wwjj1oarsdq_small.jpg" alt="img2.jpg"></a></p>
<blockquote class="short">
<p>Andela’s Lagos, Nigeria HQ</p>
</blockquote>
<p>Github and consequently the pull request was a huge inflection point for distributed engineering teams — it decoupled the ‘work’ required from the ‘integration’ of it. Now, the challenge at hand is building off that to come up with the “pull request” that works for the shared context of a company. Can any one of our 500+ employees, whether an engineer or an operations associate, get up in the morning and figure out exactly what they need to get done, do the work, submit the request, benefit from continuous integration, and know that they’re improving the system daily — even if they’re in a time zone that’s 8 hours away from their other locations?</p>
<p>We’re getting there, but it’s not easy. Over the next three blog posts, I’ll dig into how to build dynamic systems and controls for distributed teams, how to develop people in a distributed environment, and how to scale distributed teams in a high-growth startup. Stay tuned!</p>
<h2 id="part-i-building-dynamic-systems-and-controls_2">Part I: Building Dynamic Systems and Controls for Distributed Teams <a class="head_anchor" href="#part-i-building-dynamic-systems-and-controls_2">#</a>
</h2>
<p><a href="https://svbtleusercontent.com/p1doaxvfu6elkw.png"><img src="https://svbtleusercontent.com/p1doaxvfu6elkw_small.png" alt="img3.png"></a><br>
Great processes lead to great distributed work. But guess what? Very few teams, especially in the startup world, have great processes. Unless you’re old and stodgy and have had the same processes forever, which never happens, things are probably changing too quickly.</p>
<h3 id="a-resultsonly-work-environment_3">A Results-Only Work Environment <a class="head_anchor" href="#a-resultsonly-work-environment_3">#</a>
</h3>
<p>There isn’t a playbook that works for all distributed companies, whether we’re talking about partially distributed (i.e. two of your engineers decided to move to Portland) or fully distributed (i.e. Automatic, the $1B company with 400 global employees <a href="https://www.inc.com/glenn-leibowitz/meet-the-ceo-running-a-billion-dollar-company-with-no-offices-or-email.html">working from wherever they please</a>).</p>
<p>There’s also a difference between the company that’s been building distributed processes from day one (where I’m coming from with Andela), and the company that’s trying to go distributed at day 500. The latter, as you might imagine, presents a greater challenge, as managers are tasked with altering existing processes to accommodate their new remote team members. In both cases, however, it’s essential to build out processes one by one that help everyone exchange feedback, elevate challenges, and communicate clearly without relying on face time.</p>
<blockquote class="short">
<p>Ultimately, a distributed work environment forces managers to relinquish control. </p>
</blockquote>
<p>Ultimately, a distributed work environment forces managers to relinquish control. When you’re working asynchronously, you can’t have nearly as many interactions back and forth to figure out a problem. You can’t have team members blocked. As a result, distributed forces you to push out autonomy and decision making to your team.</p>
<p>How do you do this? You create systems of measurement where everyone has buy-in and understands explicitly the KPIs that they’ll be measured on. The measurements should be as simple as possible, so you’ll need to break down problems into smaller pieces to make solving them easier. At the end of the week, your goal should be to have one number for each engineer and one number for each of your teams, so you can objectively know how well a team is doing and how much of your attention they need.</p>
<p>Once you’ve chosen the measurement, and decided on a benchmark, you throw the team out the door and see how it goes.</p>
<p>This only works if you recognize that these systems of measurement are totally fallible and that they’ll change as you grow. These aren’t do-or-die measurements, they’re ways to gather information about what’s wrong — and inform future systems of measurement. You’ll probably feel like you’re giving up a lot of control, but if you’re still getting the results you want, then who cares?</p>
<h3 id="signal-vs-noise_3">Signal vs. Noise <a class="head_anchor" href="#signal-vs-noise_3">#</a>
</h3>
<p>The major challenges around remote work come down to signal versus noise. When you’re relying solely on Slack, email and Google Hangouts, all of that information is signal, and it carries the same sense of urgency or severity. This presents a challenge for managers, because when a colleague says, “you know what, this was frustrating,” you need to know whether that frustration is at the bottom of their mind or the top — in which case, it’s something you need to deal with immediately.</p>
<p>In a distributed work environment, in other words, you don’t have the noise that helps you calibrate how serious the signal is. Getting a beer with a team member is wonderful noise because you get to know that person well enough to understand what’s important to them and therefore calibrate your communication.</p>
<blockquote class="short">
<p>Teams that are new to distributed tend to react to everything, which leads to a common problem: signal overload</p>
</blockquote>
<p>Teams that are new to distributed tend to react to everything, which leads to a common problem: signal overload. These teams suffer from an overload of information across their Slack channels, Google docs, Github, Trello, etc. Discovery of information is chaotic and time consuming, and friction rises in communication when information doesn’t have a place to settle.</p>
<p>As a distributed manager, you have to make sure that information is flowing openly and that support requests coming in have a place to live. When you get feedback, it’s essential to have the processes in place to distill that information into something valuable and not forget about it. For instance, once a Github issue is created, it’s really easy to collaborate and have a focused conversation around that issue — this is because this issue serves as a shared context, an ‘artifact’ if you will. Trello is a great tool to capture disparate information, localize a conversation around it and then assign a process for resolving it. Consistent retrospectives, explicitly documented on google docs, are wonderful for making sure all voices are heard and working through systemic issues as a team.</p>
<p>In a world of signal overload, you need to make sure you’re not missing the right signals in your communications.</p>
<h3 id="managing-slack-overload_3">Managing Slack Overload <a class="head_anchor" href="#managing-slack-overload_3">#</a>
</h3>
<p>Slack is incredibly overwhelming, and it’s all signal. I’m sold on Slack, and our entire team uses it, but it’s a tool — and like any other tool, you can easily abuse it.</p>
<p>In its worst form, chat allows us this “<a href="https://m.signalvnoise.com/is-group-chat-making-you-sweat-744659addf7d">always on meeting</a>” where nothing is defined and action items aren’t carried forward. At its best, it’s an asynchronous tool to keep everyone apprised and stop the back-door, one-to-one conversations. <a href="https://blog.hipchat.com/2016/02/05/chatops-guide-evolution-adoption-significance/">ChatOps</a>, as a development technique, is fantastic — for instance, using bots to deploy so everyone knows what’s happening.</p>
<p>As with most technologies, you need the tool to be able to create the behavior you want, but you need a culture change and belief change in order to use the tool effectively. Slack is a tool to hash things out, but the result has to live in a designated place where it can be acted upon and solved.<br>
<a href="https://svbtleusercontent.com/usbs3qkrnunvxa.png"><img src="https://svbtleusercontent.com/usbs3qkrnunvxa_small.png" alt="img4.png"></a></p>
<p>Using Slack effectively means getting everything into public channels — which helps reduce the one to one to one direct messages which serves only to obfuscate problems. I believe the health of an engineering team could be measured by how many issues are raised and resolved in a given time period, and how fast that iteration is. The goal, then, is to get those issues to be public immediately, and broken into small enough pieces so that they’re resolved as quickly as possible.</p>
<p>The more things that are discussed in public channels, the more resolutions are happening and the greater circle of people who can participate and witness those resolutions which acts as a feedback loop — who doesn’t want to resolve issues collaboratively? If things stay in private, they tend to stay unresolved for longer.</p>
<p>It’s not as simple as it sounds. If you’re operating in an organization with over 500 people, like Andela, channels are good to set topics, but they get tough to manage. We’re still in the early days of understanding how to cultivate these communities and how to set KPIs to get the team focused on improving our chat behaviors.</p>
<blockquote class="short">
<p>Great distributed teams are the result of good processes.</p>
</blockquote>
<p>To tie it back: Great distributed teams are the result of good processes. Good processes are focused on results, finding the right home for information to live, and making sure your team surfaces problems publicly so that they can be dealt with. In the next post, I’ll speak to the particularly difficult challenge of developing people in a distributed environment.</p>
<p>Special thanks to <a href="https://www.linkedin.com/in/christine-magee-60342319/">Christine Magee</a> for her excellent editing and work on this post.</p>
tag:scottcarleton.com,2014:Post/premature-optimization-is-the-root-of-all-evil2016-11-21T14:33:41-08:002016-11-21T14:33:41-08:00Premature optimization is the root of all evil<p><img src="http://imgs.xkcd.com/comics/is_it_worth_the_time.png" alt=""></p>
<blockquote class="short">
<p><a href="https://xkcd.com/1205/">Relevant XKCD</a></p>
</blockquote>
<p>This past week a valuable conversation came up with our DevOps team at Andela that I’d like to share here. For context, they were building out a method to automate our development environment using <a href="https://www.ansible.com/">Ansible</a> which is a fantastic tool and markets itself as entirely appropriate for this situation - so of course, they were a bit surprised when I kept questioning it’s purpose.</p>
<blockquote>
<p>The ansible build scripts are a great MVP for this problem. It’s clear that you thought through a lot of the issues and chose tools that would be able to grow over time, handle a wide variety of use cases and allow for code reuse.</p>
<p>The reason I’m pushing on the decisions and asking lots of questions is because I know you all aspire to be great, truly world-class developers and I’d like to help you get there. Here are some things I would expect from a great developer on this project</p>
<p><em>Get something ‘working’ as quickly as possible</em></p>
<p>Software is a very unique type of engineering. It has more complexity than any other engineering field because that <strong>complexity is controlled not by the problem, but by the solutions we create.</strong> Luckily, software also has the fastest feedback loop of any type of engineering. We get to find out if our solutions work really, really quickly. Because of that complexity and uncertainty, we should strive towards the simplest solution possible. This means a solution that is easy to teach and easy to amend – and successful software is always amended. The next step is to flush out all the ‘real’ problems quickly and not worry about the ‘potential’ problems. The best way to do that is to create something quick and dirty that works, so that we can uncover any ‘real’ problems.</p>
<p>It feels like the dev environment consists of a VM, a couple of dependencies that can be all installed from one package manager and some repo downloads. From that, the simple, dirty solution that I can envision is a bash/python script that runs down the list and installs everything. Once that is working and is being <em>used</em> by developers, we’d be able to see what problems arose and fix them. If the problem was that the script was becoming too difficult to alter, I’d look into modularizing it. If the script needed rollback functionality because the developers that used it needed to rollback a lot, than I’d look into adding that functionality. If parts of the script needed to be reused for other new projects, than splitting up into reusable roles would make sense. All these added features could be done with confidence because we would already have a script that we knew worked and satisfied our customer’s needs - our customer’s being other developers.</p>
<p>There could be a moment when switching from a script to an ansible system would make a lot of sense because our script was in such heavy use. The key is that you want to <em>feel</em> that pain instead of <em>predicting</em> that pain because that’s how you know you’re solving a real problem and not just one that you think exists. </p>
<p>All this to say I am really impressed by your work on this. You’ve created a solution that solves a real need for the company, which is the most important thing we’ll do as a team. We’ll learn from this project, from each other, and from our users so that next time we can be better, maybe even great developers. </p>
</blockquote>tag:scottcarleton.com,2014:Post/simplicity-is-the-hardest-problem-of-all2016-10-03T15:11:33-07:002016-10-03T15:11:33-07:00Creating simplicity is the hardest problem of all<p>In a former life, I was a ‘nuke’ - a nuclear engineer. No “ifs, ands or buts about it”, nuclear engineering is complicated and I was attracted to the field because of this complexity. While I was there, family and new acquaintances were always awed when I said what I did. In fact, when I was fundraising for <a href="https://www.artsicle.com/">Artsicle</a>, saying “former nuclear engineer” was often enough to convince VCs I was “smart.” It felt really good</p>
<p>The problems in nuclear engineering are complex. On my team, we created mathematical solutions to prove, without a shadow of a doubt, that a particular piece of piping wouldn’t crack over 80 years. This required months of hard work, spanning disciplines from fracture mechanics to applied mathematics, and using fun tools like FORTRAN and super computing clusters. This level of complexity made everything harder and slower. New employees required months of onboarding to understand our process. Iterations were painfully slow. One analysis I wrote required 3 days to run, meaning a single trivial bug in my code could cost a week of work. </p>
<p>Was all this complexity needed? </p>
<p>No. The complexity made it sexy, but left the industry blind to opportunities to simplify their processes and make more progress. When you have the hardest problems in town, you can attract great talent who are drawn to big, sexy problems. You can keep smart people occupied, hard at work and not asking hairy questions like “why are we working on this in the first place?”. </p>
<p>Or you can try a different road - the road to simplicity. It’s easy to get excited about sexy hard problems, but I believe the really hard work is building simple, useful solutions. </p>
<p>Let’s take the pythagorean theorem as an example. It looks like a a stroke of genius:</p>
<p><a href="https://svbtleusercontent.com/tqsbetqisksvla.png"><img src="https://svbtleusercontent.com/tqsbetqisksvla_small.png" alt="256px-Pythagoras_Euclid.svg.png"></a></p>
<p><em>a</em><sup>2</sup> + <em>b</em><sup>2</sup> = <em>c</em><sup>2</sup></p>
<p>What we don’t see is all the hard work it took Pythagoras to make that proof happen, by simplifying it down to its most basic parts. You don’t see the painful moments of asking questions, feeling inadequate and striving for the simplest solution. By taking the time to simplify, Pythagoras created a formula that is infinitely more powerful, used for generations. </p>
<p>Many times, we take the other path - the road to complexity. We revel in our complex problems, creating equally complex solutions that require days to run and months to explain. We feel smart, because no one understands what we do. It’s too complex to explain anyway. </p>
<p>Many engineering teams today have this kind of culture, which I believe is contrary to our real purpose of simplification. We shouldn’t be trying to look sexy - we should be trying to simplify everything to create the best solutions. How do you do this? </p>
<p>First, you create a culture of teaching. By hiring junior engineers and regularly rotating individuals among teams, you are constantly needing to teach others. Teaching is a fast way to identify complexity and opportunities to simplify. Every time you find a point of friction in your teaching, take the time to simplify your processes, code or concepts. </p>
<p>And second, celebrate simple. I believe simple is the sexiest solution. A truly simple solution is often hardest to attain and provides the most value. It makes change, refactoring, abstracting, onboarding and a whole lot of other ‘ings’ easier. When we celebrate simple, we celebrate the sexy work of chipping away at problems and making real, measurable progress. </p>
tag:scottcarleton.com,2014:Post/hackathon-trials-tribulations2016-09-20T17:06:11-07:002016-09-20T17:06:11-07:00Hackathon Trials & Tribulations<p><a href="https://svbtleusercontent.com/awrgk4gml7sw5w.jpeg"><img src="https://svbtleusercontent.com/awrgk4gml7sw5w_small.jpeg" alt="imprompt-io.jpeg"></a></p>
<p>The team traveled a total of 25,000 miles for this. Two engineers flew from Nigeria, two other team members came from across the US. And me. The new guy, flying from NYC on his 4th day on the job. All to try and get a hack done in the next 24 hours at TechCrunch Disrupt. What am I doing here? I thought I was too old for this. </p>
<p>It all started with a cool idea - as it should. Wouldn’t it be awesome to pull someone into a meeting at a moment’s notice? “Hey Alexa, is Tolu available?” –> “Yes she is, setting up a Google Hangout now.” Or “She’s busy in a meeting”. Or “It’s after work hours in Lagos”. Sounds great, right? But as engineers, we have to figure out the nuts and bolts of <em>actually</em> getting this done, in less than one day.</p>
<p>For software engineers, there’s something incredible about a hackathon. The pressure, the cycle of asking the questions, of finding the hurdles and overcoming them. There’s a purity to it. It’s an engineering rush to build quickly, determine tradeoffs, and go with the best solution. There’s no waffling, no politics, and no ego when a team is this united in pursuit of getting something working, fast.</p>
<p>After a few discussions and diagrams, we settled on an architecture:<br>
<a href="https://svbtleusercontent.com/thnqx5aejbfdw.png"><img src="https://svbtleusercontent.com/thnqx5aejbfdw_small.png" alt="impromptu-design.png"></a><br>
This is starting to feel pretty complex for a hackathon project. There are a lot of pipes to hook together and get working in sync. In my experience, pipes mean leaks, data incompatibility and trusting the network - which is never a good idea. On the plus side, this architecture allows the team to divide up and build in parallel so that we can make the best use of our time.</p>
<p>We set to work. </p>
<p>The questions, tradeoffs and decisions started coming fast and furious.<br>
Does anyone know a good Node library Redis pub/sub? Should we use Heroku with Node.JS or a full blown AWS infrastructure? What is this AWS Lambda beast? Does anyone know the basics of Amazon Alexa? What the hell is an ‘utterances’ file? This is really the best part of hackathons. You come in, not knowing anything about the APIs or tools you’re going to use and you run into hurdle after hurdle to scale those walls within hours.</p>
<p>A few hours in and we’re making progress. But there are new complexities at every turn. This particular team has never worked together before. Can we really get this all done?</p>
<p><a href="https://svbtleusercontent.com/18xum82nmbafg.jpg"><img src="https://svbtleusercontent.com/18xum82nmbafg_small.jpg" alt="IMG_2464.JPG"></a></p>
<p>Doubts start to creep into my mind. I’m worried about failing - for my own ego, but also for my team’s. I’ve known them less than a week, but I desperately want to see them succeed. I wonder at what point I need to jump in, steer us towards something simpler, and “save the day”. Calculations are running through my head, estimating the likelihood that the Lambda system will be reliable. And how likely is the Heroku bot going to be resilient to failure scenarios? I hold my tongue for now, but look for opportunities to improve our chances of success.</p>
<p>We’re getting some movement. I think maybe this will work. But there’s so much left. And nothing is tested. Each change we make could bring down the system. It’s getting harder to isolate the variables when debugging as the codebase grows. Oh, and we’re getting tired. </p>
<p>If we’re going to finish this, we need to keep our speed up. I start looking for ways to optimize our process. </p>
<p>I find one. We have basic AWS Lambda code working. Updating this code requires selecting our local files, zipping and uploading it to AWS. For me, this feels like a ridiculous deploy process. And it’s messing with the entire development process. Every time we make changes to our javascript script we have to upload to Lambda to see if it works. Pssh! This is crazy in a world of continuous integration - real-time feedback cycles that I see as a necessity towards building solid products. If I’m not getting feedback in under a minute, I want to build the tools to be sure I can. I start work on a better pipeline.</p>
<p>Fast forward an hour and a half and I’m not making any headway improving our development environment and deploy script, which would automatically test our scripts and deploy it with one command. I look over at my teammate, Brice, and realize he’s already done 15 or 20 iterations of tweaking, compressing and hand uploading in the time I’ve spent trying to optimize our deploys. Shit. I’ve made a big mistake. I’ve wasted over 5% of my total hackathon time trying to make tools, instead of tackling hurdles that would get us closer to finishing an awesome hack. This entire time Brice was making real progress, and what was I doing? Futzing around with unnecessary tooling that wouldn’t matter in a few hours. </p>
<p>How did I screw up this badly?</p>
<p>Engineering is a discipline of trade offs. It’s not a science, not a set of best practices to be rote memorized and spouted out. It’s about considering the entire problem set, the requirements at hand and making the right tradeoffs to attempt a solution. I’d missed the mark because I hadn’t taken into account the time frame I was working in. With 24-hours to build something awesome, every wasted hour is critical, and every optimization pointless. </p>
<p>Luckily, engineering is a team sport and my team knew exactly what to focus on. With a few hours left to hack, I set aside my uncompleted script and got back to the real work. It was a scramble to the end, but on Sunday afternoon I watched nervously as our demo team took the stage. Ugly deploy system, leaky pipes, and questionable network be damned - in the moment, everything works perfectly. We <a href="https://techcrunch.com/2016/09/11/with-a-team-hailing-from-around-the-world-imprompt-io-hacks-on-the-fly-communications/">built the right tool</a> for the job. </p>
<p><a href="https://svbtleusercontent.com/hubaqoj2nfxna.jpg"><img src="https://svbtleusercontent.com/hubaqoj2nfxna_small.jpg" alt="imprompt-team.jpg"></a></p>