There are several paths to starting a career in software development, including the more non-traditional routes that are now more accessible than ever. Whether you're interested in front-end, back-end, or full-stack development, we offer more than 10,000 resources that can help you grow your current career or *develop* a new one.
It's time to make noise. Developers need to take back their happiness and their productivity. But where should they start? On this week's episode of Dev Interrupted, we're joined by Justin Reock, Field CTO and Chief Evangelist at Gradle. With a mission to mitigate the toil, friction, and frustration felt by so many developers, Justin has become a tireless advocate of Developer Productivity Engineering. Listen as Justin explains DPE by exploring the connections between productivity, developer experience, and joy. Episode Highlights (3:50) What is Developer Productivity Engineering? (8:14) Creative vs. destructive flow (16:21) Metrics and visibility (22:37) Open-source supply chain security (24:01) Blockchain, AR, and VR Episode Excerpts How Facebook, Netflix, and LinkedIn handle developer productivity engineering Justin: That's one of the things that actually differentiate DPE from DevOps a little bit is that there's the human factor, right? Like the platonic ideal of a DevOps team is supposed to be not a team at all, right? 100% automation, no humans in the loop, right? But with developer productivity, you have to have humans cascading this practice, caring about, you know, the metrics that they see on the dashboard and then correlating that to developer experience. Without that empathy, then you don't get the focus; you don't get anything actionable that really changes the culture of the business. So that is a differentiator is that you need those people to be thinking about these problems. But then you know that that ends up, and ideally, these people have written code, right? I mean, right? It's very special you come across these developers who, like, truly care more about the performance of their team. And what the whole team is, is going through in terms of the developer experience versus their own experience writing code, and they're everywhere. They're in every organization. I mean, that's the thing is, like, a lot of folks have already been doing DPE. They just haven't been calling it that, you know, or maybe it's a part-time, couple hours a week that some development leads spends on productivity. But what we have to see now is a shift in focus to making this a center of excellence. The companies that are really doing this, right, you know, the Facebooks, the LinkedIns, the Netflix, you know, they have dedicated teams of hundreds, productivity engineers, it's 1,000s of developers. And that's the only way, I think, to kind of keep enough of a focus in the industry to allow this to be a transformative change as opposed to just minor tweaks. Do CEOs Care About Developer Experience? Justin: I'm a big fan of the whole Malcolm Gladwell 10,000 hours for expertise type of thing, but is it 10,000 hours waiting on a bill to complete, or is it 10,000 hours writing code? So obviously, if you're able to spend more time on that part of your learning and your experience, that only makes sense that you'd be able to onboard faster. You won't run screaming from the industry because you're like, oh, this is not what I signed up for. This sucks. So, I think that I mean, there's all these impacts, and the time is right for it now. I mean, Gartner released a CEO report a couple of months ago, the 2022 CEO report, and it was like, I don't remember the exact statistic, but it's like a 40% increase in terms of CEOs that are now... That they actually have Developer Experience on their radar, which is very good, but also very acute, right? I mean, just a couple of years ago, it was way low on the list of CEO concerns, and now it's one of the top concerns. Engineering Insights Before Anyone Else... The Weekly Interruption is a newsletter designed for engineering leaders by engineering leaders. We get it. You're busy. So are we. That's why our newsletter is light, informative, and oftentimes irreverent. No BS or fluff. Each week we deliver actionable advice to help make you - whether you're a CTO, VP of Engineering, team lead, or IC — a better leader. Get interrupted.
As the world of cloud computing continues to evolve, the need for effective FinOps strategies is becoming increasingly important. In this article, we will explore the critical role of developers in effective FinOps strategies and the benefits of FinOps for technical expertise and career growth. Defining FinOps: Why Developers Are Critical to the Equation Let's begin by briefly revisiting the definition of FinOps. The FinOps movement has been steadily gathering momentum since its inception in 2018. The FinOps Foundation defines FinOps as ‘the practice of bringing together Finance, Business, and Technology to master the unit economics of cloud for competitive advantage.’ FinOps is essentially a set of principles and practices that enable organizations to align cloud spending with business objectives to get maximum business value from the cloud. The 2023 edition of the State of FinOps survey by FinOps Foundation highlights that the biggest challenge reported by FinOps practitioners is enabling engineers to take action. For companies to take full advantage of cloud technology and benefit from its efficiency and cost savings, they need to ensure that their developers are involved in FinOps strategies. Developers play a crucial role in these strategies — they are responsible for understanding how spending on infrastructure affects product delivery quality and have an important part to play in establishing cost optimization processes. Involving developers in FinOps initiatives helps promote visibility into costs and a better understanding of how their decisions impact financial performance. Moreover, developers are best placed to understand the complexities involved in infrastructure optimization — from identifying resource bottlenecks and developing techniques for reducing cloud costs to developing code for better scalability. They are well-versed in cloud computing concepts such as microservices, containers, and serverless architectures which make them ideal partners in creating effective infrastructure optimization strategies with non-technical teams while complying with security standards and reducing costs. Engaging in FinOps not only does it get them closer to the business processes that their code supports but also helps them evolve their technologies from cost centers into profit centers. FinOps: The Future of Cloud Optimization and Developer Empowerment While there is growing agreement on the benefits of FinOps for companies, the State of FinOps report suggests that there are still barriers preventing engineers from fully contributing to FinOps strategies. This indicates that developers may not be fully aware of the many advantages that FinOps offers. Let’s take a moment to explore a few of its key benefits: Enhanced Automation: Through deeper collaboration with other departments and stakeholders, developers can build automation processes that align with the business strategy and improve time efficiencies. Greater visibility into their projects: By enhancing their understanding of the budget and cost drivers behind their projects, developers can gain deeper insight into their work, helping them to make better decisions and ultimately deliver more efficient solutions. Improved Data Tracking: The use of data tracking tools and tags can provide developers with greater insights into how resources are being used within their organization — allowing them to identify any potential areas for improvement or cost reduction. On top of the technical benefits of FinOps, developers can also benefit from greater career prospects. As the FinOps movement continues to grow, employers are looking for professionals who can offer a combination of technical and financial acumen, making developers with FinOps experience highly desirable. FinOps is ushering in a new era for developers, offering a unique opportunity for them to take control and make an impact. By using their technical and analytical skills, developers can play a pivotal role in helping their organizations succeed while also improving their own career prospects. Want to stay up-to-date on the latest FinOps strategies and connect with like-minded professionals? Join the FinOps Foundation today and gain access to exclusive content, training, and events.
When you’re navigating new territory, it is essential to have a guide. And if you want to grow your skills as rapidly as possible, it helps to learn from someone who has done it before. Why Use an Engineering Advisor? An advisor is someone who helps you produce better results with your work. They: Suggest new ways to solve problems. Help you navigate problems you haven’t dealt with before. Point out mistakes you might be making. Accelerate your career growth. Provide new mental models for thinking about your work, giving you more tools for your leadership toolkit. How Do Executive Advisors Work? Every advisor is different, so you should find out what approach a prospective advisor uses. I think my approach is fairly common, so let me share how it works with my practice: With most of my clients, we conduct working sessions. They are one-hour sessions and are weekly, biweekly, or monthly. In these sessions, my client brings their current problems, and we problem-solve them together. Each of us brings an essential part to the working session. I bring a lot of experience (both in terms of years doing this, and across many companies). I’ve seen it all before. My clients have their own experience and expertise. But most importantly, they have much better context on the problem and environment. We talk through a few ways to solve each problem, and we review the tradeoffs of those approaches. I usually suggest solutions my clients wouldn’t consider, and I share tradeoffs they would miss. They, in turn, point out ways the environment may bias the solution in a particular direction. Some of my clients use me to test their plans. They’ll share what they’re thinking, and have me walk through the tradeoffs, or suggest some alternatives they might not have thought of. We walk out of these sessions with solid plans and new ways of addressing problems. It’s like pair programming, but for leadership! Other advisors may have different styles or ways of operating, so be sure to inquire into their approach. When To Use an Advisor I see several profiles of leaders who reach out for advisory help: Leaders who are in new territory: Typically leaders approach me when they’re getting in a little over their heads, or their current approaches seem to break down. (This often happens at ~20 engineers or ~50 engineers in an organization). Symptoms are too many direct reports, too much relying on them, engineering velocity slowing down, or quality problems emerging. Leaders who are promising but need support: Often very talented leaders who have a little fewer years of experience seek out advisors to make sure they’re well supported. Sometimes their boss may even insist on it. This can help bright and capable leaders step into situations that may otherwise feel risky for the company. (Hint: You can use that to your advantage to get companies to take a risk on you by pairing the responsibility with an advisor.) Leaders who are growth-minded and want to be as effective as possible: These leaders are aware that their growth is magnified if they get good feedback on their work, so they seek to accelerate their growth by choosing an advisor who will give them new perspectives. Leaders who are part of a work culture that encourages growing their leadership: Some companies invest in their leaders because they view it as a high-leverage place to invest. Making a leader 10% better has a greater than 10% impact on their area of the company. In these companies, most of the senior leaders have executive advisors or coaches. How To Choose an Advisor I recommend you interview a couple of advisors to determine which person is best for you. Ask people in your network for recommendations. Select a few, and contact them. With my potential clients, I like to do a practice session. This gives the potential client a feeling of what it’s like to work together. Ideally, they will do the same practice session with a couple of advisors, and see what kind of insight they get from each person. They should also evaluate how comfortable they feel being vulnerable or showing their weak areas with the advisor. Do keep in mind that sessions will get better over time as you develop a working relationship together, but the sample session will give you an idea of what it’s like to work with the person. I recommend asking for a sample session. What To Look For What should you look for in an advisor? Someone who has been through the stages you’re going through Someone you communicate well with Someone you can be vulnerable with Someone who listens as much as they speak Someone who doesn’t have the same solution to every situation The last one is something I think it’s important to emphasize. How flexible is the advisor’s thinking? Do they respond to every situation with the same solution? That’s often a red flag. Rates for Advisors Rates vary greatly depending on the advisor. I’ve seen rates that vary by an order of magnitude! If you’re on a budget, you can probably find someone fairly inexpensive. But you have to be careful with your choices. You’re hiring someone for their expertise, not just for them to coach you (more on the difference between coaches and advisors later). Ideally, your company should be paying for the advisor. What I tell companies is to use this heuristic to determine whether the rates are reasonable for an advisor: If you took the yearly cost of the executive advisor, and compared it to how much it would cost to hire an additional engineer, how does it compare? Compare both the anticipated impact of the advisor and the cost. When you consider the impact on the company, it’s generally a very smart investment, even if it looks quite expensive. A good advisor can help you avoid expensive mistakes, and improve the trajectory of an entire department. That’s often worth it even if it’s quite expensive. Advisors can be expensive, and even feel out of reach for individuals. Why? Consider the economics of the situation. A highly experienced engineering leader can command a salary of $300-500k/year, plus 0.5-2% of the equity of a company, and bonuses. Total comp can be $350-$1MM a year. Advisors also have a lot of overhead to just be an advisor. To give you an idea from my own consulting: I have 4 or 5 hours of meetings with prospective clients for every client that signs up (and I think that’s a good ratio). I need to have about four hours of meetings a month just to be sustainable as a business, and it fluctuates greatly. I have to manage taxes, health insurance, and deal with unpaid vacation. When you add all these things up, the rates can end up being higher than you might expect. I personally provide a 50% discount for individuals, because otherwise many of them can’t afford it. And many of them find even the discounted rate out of their reach. If possible, go through your company. An easy way to ask about this is to ask if they offer executive coaches or executive advisors. If they don’t, ask if they’d be open to it. Many leaders don’t want to seem “weak” by asking for this. But many companies do offer this kind of investment in their employees, or are willing to. You may be surprised that the person you’re asking already uses an advisor! Most advisors charge either hourly, or by the number of meetings. My own rates are monthly charges, based on the frequency we plan to meet. That seems to be pretty common. What About Using an Executive Coach? Here’s what ChatGPT says is the difference between using a coach and an advisor. I have to admit it’s a good summary of the difference: “Both advisors and coaches can provide guidance and support, but there are some key differences between the two roles. An advisor typically has specialized knowledge or expertise in a particular area and offers advice based on that expertise. They may provide recommendations, opinions, or solutions based on their experience and knowledge to help a person make informed decisions. On the other hand, a coach is more focused on helping a person achieve their goals and develop their skills or abilities. Coaches typically ask questions and use various techniques to help their clients identify their own strengths and weaknesses and work towards self-improvement. Coaches may also help their clients create action plans and hold them accountable for their progress. Another key difference is that advisors tend to have a more directive approach, while coaches are more non-directive. Advisors often offer specific recommendations and may even make decisions for their clients, while coaches help their clients find their own solutions and strategies. Overall, both advisors and coaches can be valuable resources for people seeking guidance and support, but they have different areas of focus and approaches.” You’ll find that there is a continuum between the two. Most advisors also do some coaching. Some coaches also do some advising. My advice for engineering leaders is to find someone who leans towards advising. The reason for that is that having deep experience in engineering leadership is something that is worth a lot. There is a wide body of knowledge and expertise that you will be able to tap into from advisors that understand that domain well. But this does depend on the goals you have in mind. If you’re looking to be a more effective communicator, a coaching approach may be more appropriate. And if you’re wanting to have more perspective as a leader, a coach may be more appropriate. Both are reasonable options. I would look at this as a spectrum that you can use to evaluate people you’re considering.
Building a new version of your product is an exciting endeavor, but it can also be an overwhelming one. In the earliest days of a startup, there tends to be little formal structure in place, which is usually for the best! Everyone’s wearing numerous hats and just trying to get the product and company off the ground. It’s a time of innovation and creativity. When we built the first version of our product, we didn’t have a dedicated product team. That changed with version two, bringing new opportunities and challenges along with it. Through trial and error, we moved through several iterations of workflow, communication, and reporting. The key was balancing input from both the engineering and product teams while also balancing planning and innovation. We learned a lot from this endeavor and, in addition to successfully updating our core offering, gained some important insights about how to set yourself up for success even (and especially) as your company grows. With that in mind, here are my top three tips for success to stay on track as your engineering and product teams grow. 1. Center the User To successfully build a new product, your engineering teams and product team must be in alignment. Of course, alignment can happen in many ways. If you simply have the engineering team taking orders from the product team, it will likely result in a worse outcome. Instead, the best way to align engineering and product is to make sure both are focused on users. Equip both teams with sufficient knowledge about the pain points and needs of users, so they can be checking in with the product from a user perspective on an ongoing basis. Consider a situation where an engineer suspects that following directives from the product team will result in clunky UX. They don’t necessarily have to solve the issue, but they should raise the concern. I’ve seen engineers do this quite effectively — asking if it’s possible to simplify the design, for instance. This speeds up development and, in the end, results in a product that is more valuable to users. By centering users, you’re aligning the goals of both teams and empowering engineers to push back and innovate when necessary, as opposed to simply nodding along and building exactly what the product team suggests. 2. Prioritize Reporting Alignment also comes as the result of ongoing communication. To that end, I suggest implementing a weekly reporting system. When both the product and engineering teams are being vocal about what they are working on each week, it helps everyone stay on the same page and makes the two teams feel more like one. Some updates might include: What are people working on at the moment, and what have they achieved? What else is left? What roadblocks or hurdles have slowed down work or might do so in the week ahead? Once again, both teams should be contributing updates. In the past, there were times in which there was tremendous communication within each team but a lack of communication outside of them. Sometimes, we failed to update the roadmap when a feature was complete. Other times, a product might be released as a minimal viable product, so it was considered complete on the roadmap, but the reality was a little different. Being proactive about, first, making sure the roadmap reflects the reality of the work taking place and, second, making sure communication happens on an ongoing basis is extremely helpful. To make reporting sustainable, choose a platform that’s easy to use. At Prefect, we conduct weekly reporting in a Slack channel. We also sync up quarterly to review larger goals and check our progress against them. 3. Leave Room for Innovation Speaking of the roadmap, one of the most difficult things to balance when the building is how much engineers should stick to the roadmap versus going off-script to build something they’re more excited about. The only way to know if you’re following the roadmap too closely is to have a strong connection with your engineers and to speak with them on an ongoing basis. Ask them: Do they feel like they've got the space to go and be creative, or do they feel like all of their time is taken up with roadmap items and prescriptive work? Of course, there are times when you need to follow the roadmap almost exactly, whether because of a deadline or user demands. When the roadmap has been disclosed to the board and current customers, swaying from it can be more challenging because several audiences are counting on the agreed-upon direction. At the same time, being too prescriptive about particular features can be really harmful to both the product and the morale of the engineering team. A 50/50 balance is a good goal. Is about half of your engineering team’s work creative or self-directed, or are they simply managing requests and checking boxes? The Bottom Line New workflows can feel daunting, but they’re also opportunities. If there’s one key takeaway, it’s that balance is paramount. As your product and engineering teams grow, it’s imperative to strike the right balance between adhering to the roadmap and allowing for creativity. But the first two tips— ongoing communication and alignment (by having everyone focus on the user) lay the foundation for finding this balance. That’s not to say challenges won’t arise. But with the help of these tips, your product and engineering teams will be better suited to handle them — and primed for making the best possible product in the process.
Field CTO is a job role that comes up more and more in software companies. There is no standard definition for this job role. As I regularly get the question about what a Field CTO does, this blog post summarizes a few general characteristics and then explores my daily life as a Field CTO. The post concludes with the answer to how you can also become a Field CTO at a software company in your career. General Characteristics of a Field CTO Search through business and employment-focused social media platforms like LinkedIn or jobs networks and portals like Indeed or Glassdoor. You will see many of the following characteristics, experiences, and tasks of most people that own a position as Field CTO: Meet many stakeholders across entire customer projects and sales lifecycles: Work with prospects/customers and partners (like cloud service providers, other software vendors, and system integrators) to ensure customer success. This includes joint planning of customer projects, a strategic roadmap for the enterprise architecture, or technical partnerships. Talk business and tech in the same meeting: Explain the product portfolio and business value of your solution on all levels, including business executives, tech executives, and whole project teams with project leads, architects, engineers, and business people. Evangelize the product portfolio and success stories: Perform internal and external events and create public content about case studies, technical architectures, and the business value of your solution mapped to industry and business problems. Events include webinars, business roundtables, tech meetups, and international conference talks. Content creation covers podcast interviews, blog posts, slide decks, and articles in magazines/electric journals. Collaborate with product and field marketing: Close to evangelism, but often independent, work with the internal marketing to support product announcements, regional road shows, global webinars, customer case studies, and other marketing initiatives to generate product/vendor awareness and sales pipeline. Be a public spokesperson: Present the employer in public relations. This differs from evangelism, as it is much more strict, dangerous, and sensitive. The key partners are the media/press holding interviews and research analysts (like Gartner and Forrester) getting educated about the product portfolio and case studies. Collaborate with product and engineering: Provide feedback from the meetings and public events to product management and engineering teams, like new feature requirements. And the other way, present the roadmap and strategic decisions to customers. This was the general summary. In the following sections, I will go into more detail about my individual daily life as a Field CTO. My Regular Personal Tasks as Field CTO In my world, everything is around open source, cloud, data streaming, analytics, and big data. My current employer Confluent provides a complete data streaming solution that can be deployed everywhere with a cloud-native product portfolio. Let's look at my recurring daily, weekly, or monthly tasks. The mix of all the following functions makes the difference. I might not be a complete expert in any of these categories. But I can leverage and combine my knowledge and experiences across different aspects. Each section shows a few references, so you get a feeling about my work in the different areas. Task 1: Support the Success of Our Customers Customer success is a term software companies focus much more on compared to the last decades - even to the degree that whole departments are named after it. While it makes total sense to make and keep the customer happy, the cloud enforced this paradigm much more strictly as the financial success for the software vendors is based on continuous consumption of the cloud products instead of just selling perpetual software licenses. Customer success obviously increases the customers' satisfaction while using a product or service. This results in decreased customer churn and increased up-sell opportunities. Customer success is a company effort from the CEO down to the account team. You work with strategic customers on every level, including top management, decision-makers, project leads, architects, developers, etc. Here are a few things I do to support a great relationship and the success of our strategic customers. Share Technical Architectures Mapped To Real-World Experiences I map my experience from what I see from customers across industries with relevant technologies. In my case, I have worked in the data integration and analytics space since I wrote my degree dissertation at the university many years ago about middleware, service-oriented architecture (SOA), and enterprise service bus architectures. Today, working for the data streaming vendor Confluent, I focus on open-source technologies and cloud services around Apache Kafka. A Field CTO is not necessarily a deep technical expert like the consultants or support engineers. Still, the Field CTO understands the technology and how it complements or competes with other technologies. I can explain design principles for distributed computing architectures, hybrid cloud deployments, cloud-native architectures, microservices, and data mesh. As Field CTO, I understand how data streaming helps to solve business problems using these architectures. Last but not least, and maybe most importantly, I educate how data streaming fits into the enterprise architecture with other technologies and products for middleware, data analytics, machine learning, the internet of things, blockchain, and so on. Here is a concrete example where I map retail use cases for omnichannel communication focusing on use cases, not technology. Despite the technical content, this slide is also easily understood by the executives and business teams: Some Field CTOs are very technical and collaborate a lot with engineering to add technical features or improve the performance of the product together with key customers. To be very clear: That's not me. :-) Talk to Executives and Very Technical People in the Same Room A Field CTO can and has to talk at the right abstraction level. Contrary to many other colleagues involved in customer success, I do not focus on just selling our product or supporting the customer in production, or implementing a new application. Instead, I discuss the value of our product portfolio for the next customer project or the strategic enterprise architecture. Hence, a few aspects are different in my meetings compared to my colleagues from presales, consulting, or support: I usually support the early stages of a customer project or sales cycle, where a decision needs to be made about the best architecture, technologies, and strategic planning. The starting project teams get support from me to spread the benefits of their strategic decision across their organization - the bigger the account, the more often this might need to happen. I need to speak the languages of executives and technical people in the same meeting room and confidently answer questions on all levels. I interact with senior executives and technical experts within the Fortune and Global 2000, but also smaller enterprises and startups. The meetings are very different depending on the company size. An executive in a startup is often still the technical decision-maker. The mix of meetings with different kinds of companies is one of the most helpful aspects because one can learn from the other. Think about a traditional bank and a FinTech startup. The Field CTO helps connect the dots and educates companies on how others solve business problems and innovate. Share Industry Expertise To Talk at the Right Level No matter what company size, the key challenge is usually the same (and that's what most people struggle with): Talk at the right level. For instance, don't discuss technical details if you talk to a CIO. Don't even talk about the product or technology. A CIO needs to solve business problems and buys any product that helps. In my case, the CIO rarely cares if the problem is solved with Apache Kafka or any other technology. So, how do you talk at the right level? The answer is simple and complicated: start with case studies. Show knowledge of the customer's industry. Speak to customers in a language they understand. The conversations begin well if you explore a success story from another public customer in the same industry. You can go down to technologies and architectures as much as needed (or skip it if you talk to an executive or business person). For instance, if the developers ask how transactional workloads are implemented with data streaming, I go down to the API level and explain the concepts and functions of Apache Kafka's exactly-once semantics. Represent Headquarters in Other Time Zones Here is one of the biggest problems of most software companies that originate in Silicon Valley: Time zones. Actually, every startup begins with this problem, no matter if you create an innovative business model in a tech hub like Tel Aviv, Berlin, or Bangalore. I am used to working for companies that emerged in Silicon Valley. The time zone is nine hours behind my home in Germany. The Middle East, Asia, and Australia struggle even more. Sales, marketing, consulting, and support need to be regional. A software company cannot grow successfully otherwise. But what about top management, field leadership, and product management? Correct. Most of these colleagues often live close to the Pacific time zone. That's where Silicon Valley is. Otherwise, alignment in creating strategies, making decisions, and coordinating the worldwide business is much more complex. A regional Field CTO is especially helpful in regions outside the headquarters' time zone. So, even if the most significant piece of revenue comes out of the US, you might find one Field CTO for the US, one for EMEA, and one for APAC in the company. Why? Because the Field CTO in other time zones takes over some tasks of headquarters. Present and Discuss the Company Vision and Roadmap One of the most common inquiries I get, especially when traveling outside the US, is doing roadmap presentations about the company’s vision and strategy (under NDA, hence not in public events) because product management sleeps while I visit the customer. But there is more than roadmap discussions. The reality is that digital innovation usually happens first in a few countries, like the US or Mainland China. Other countries learn and repeat. The Field CTO sees innovative and successful trends and shares the news with different time zones. Two examples: Technical Example — Cloud Infrastructure: Some countries are just moving to the cloud. For instance, when I visited the Middle East a few times in 2022, the significant discussions were still about the availability of cloud providers like AWS or Azure in countries like Qatar or Saudi. Hence, these countries are forced to be years behind the US or many European countries. Business Example — Live commerce (aka social commerce): It has been a very common business model in retail in Asia for several years already. This sales innovation combines instant purchasing of a featured product and audience participation via social networks. It still surprised customers in the US and Europe when I present how Apache Kafka transforms the retail and shopping industry with live commerce. Task 2: Thought Leadership A thought leader is a known expert in a specific field. In my case, I have worked in the data integration and analytics space for many years. The topics and technologies change over time. In my early career, I focused on service-oriented architectures using Enterprise Service Bus (ESB) technologies and Batch ETL tools. Today, I focus on data streaming with technologies like Apache Kafka or Apache Flink and design principles like microservices and data mesh. But since the start of my career, I have documented the integration and data space evolution with public presentations, blog posts, and articles. I share my experiences with case studies, best practices, anti-patterns, and trends. Thought leadership means sharing experiences and educating others. There is disagreement, too. That's fine and part of why the software industry is so exciting. Evolution and innovation never stop. Trustworthy Consulting for Customers, Partners, and Community Sales and marketing are crucial for the success of every software company. Each business unit has its own goals, like reaching revenue goals or creating a lead generation and revenue pipeline. These goals sometimes conflict with focusing on the big picture of the customer and its enterprise architecture. Every software company puts itself in the middle. You won't imagine how many vendors I have seen in the integration and analytics space pitching themselves as the heart of the customer's enterprise architecture. Every company has plenty of other vendor agreements. Not everyone can be at the heart of the enterprise architecture. I always recommend using the right tool for the job. It is typically not sales or marketing that solve this conflict. It is not their task either. Independent consultants and system integrators help fix this mess. From the software vendor side, the Field CTO is a trustworthy person explaining when to use the own product portfolio and how to complement other technologies in the enterprise architecture. The beauty of open source is that you can help your colleagues and the broader community simultaneously with thought leadership. In the end, it is a win-win situation. You won't imagine how often I come into a meeting anywhere in the world, and a few people in the room from the customer already know me before I introduce myself. I articulate when and when not to use our products. Sometimes, sales reps in a customer meeting might go a little crazy inside when I present when NOT to use Apache Kafka. A Field CTO is a trustworthy advisor. Present Industry Trends Mapped to the Product Portfolio I learn daily about new use cases, technologies, and other trends across industries. Without up-to-date industry knowledge, it is impossible to be a trusted advisor to customers, partners, and the broader community. I spend at least an hour every single day educating myself. The focus here is not technology but industry developments. Podcasts are your best friend when traveling or just taking a break from work and going for a walk or run. As Field CTO, I remain current on industry trends and act as an industry thought leader and trusted advisor in internal discussions, customer meetings, and public events. Deliver tangible content (articles, whitepapers, slides, videos, demos, etc.) to be used by various business units like sales, presales, marketing, partner, product management, and others. But the content is NOT sales but trustworthy education for everyone. In my case, I get great feedback from colleagues, partners, customers, researchers, students, and competitors (!) about how my thought leadership helps to define the proper enterprise architectures and solve business problems. My presentation about use cases and architectures for data streaming across industries is a great example focusing on case studies, not the underlying technologies and products. A Field CTO confidently presents in front of audiences of all sizes (from 1 to 1,000 and more people) to communicate the value proposition of strategic and tactical concepts and architectures for complex enterprise use cases. This happens in on-site and virtual events. I deliver virtual webinars, customer tech talks, on-site conference talks, keynotes, roundtables, and in-person panel discussions every month. Nobody was born with the talent of speaking in public. Speaker training never hurt anyone. One should seek honest feedback on the presentation style regularly. Look at what kinds of international talks I give across the globe to get a better feeling for my public content. Here is a picture where I speak at Big Data Spain in Madrid: A Field CTO in a bigger company might focus solely on a single industry to go deep into conversations on all levels. I prefer another way. I am not a deep expert in one industry. Instead, I can share case studies and architectures across all major industries. Customer Meetings at International Conferences and Regional Events Thought leadership is not just about writing blog posts and doing presentations. I attend many public events every year around the world. This includes events organized by our company and external conferences. For instance, at Confluent, the most critical events are our yearly conferences in the US (Current, 2022 in Austin) and Europe (Kafka Summit, 2022 in London), plus regional events (Data in Motion tour around the world; I attended Frankfurt, Zurich, Stockholm, Amsterdam, Tel Aviv, and Dubai in 2022). I also participate in external events. One of my yearly favorites is AWS ReInvent in Las Vegas. But I am not an attendee at all these events. I usually don't have much time to attend sessions. Instead, I have customer meetings. Up to ten per day. It can become very stressful and exciting at the same time. Additionally, I usually give a talk or keynote and moderate a customer roundtable (often for executives). Looking at my slide decks and blog posts, I have plenty of success stories and architectures I can discuss on every level, from the CIO to the software developer for financial services, insurance, retail, telcos, gaming, public sector, logistics, travel, energy, automotive, healthcare, and software industry. I can adjust my content depending on the audience. For instance, if I speak at the yearly Automotive IT Congress in Berlin, I know the audience is top management from OEMs and suppliers. Hence, I present case studies about car makers, manufacturing, and mobility services. When I go to the Apache Kafka open source community meetup in Berlin in the evening, I speak about deep technical and non-industry specific general content like disaster recovery strategies for data streaming. And when we have a customer roundtable for lead architects, the conversation changes to a completely different story once again. A Field CTO Is Not a Developer Advocate or Evangelist Note that the content of a Field CTO differs from developer advocates/technology evangelists. These colleagues focus on source code, live demos, deep technical Q&A, etc. Don't get me wrong: Some developer advocates publish unique thought leadership content. And Field CTOs create code examples and demos. But the priority and focus are very different. The overlapping in the daily business is less than 10% in my experience. The Field CTO understands the market and the business in depth. The focus is on customers' problems and innovation. Mapping these challenges into the software vendor's product portfolio is a key focus area. Contrarily, the developer advocate focus is using the product portfolio of the software vendor to create exceptional code examples/demos and shares the developer experience with the community (i.e., customers and potential customers) by doing blog posts, meetups, conference talks, podcasts, etc. Having said all this, some content I create is comparable to presentations or blogs of developer advocates. For instance, I wrote a few quite technical articles on the Confluent blog. Hence, some people define Field CTO as a C-level developer advocate and evangelist. The content of the Field CTO (similar to the content of the developer advocate) is not just helping the customers, partners, and the broader community. I also use it for internal enablement. I have a detailed explanation in the next section for this. Task 3: Collaborate With Internal Teams A Field CTO is connected with colleagues across various departments within the company. And on all levels, from C-level to field teams to engineering. Collaborate With Product Management and Engineering The Field CTO supports product management and engineering with feedback from customer conversations and shares the company's strategy and vision with the customer. Here are specific tasks I do regularly. I want to emphasize that I am not the lead or expert in any of these tasks. I add another perspective from my experience (that is different because of my daily job meetings customers, creating thought leadership content, etc.): Share feedback from the field: Feedback includes ideas, complaints, and trends that I hear in my 100+ customer meetings during the year across the globe. I do monthly 1:1s with a few product managers, plus many discussions whenever I meet product managers or engineers at internal or external events. Join subject matter expert (SME) groups: Dedicated groups with colleagues from all different business units meet weekly to discuss a specific topic. I join a few of these whenever I have time. Review internal and external documents: I look at internal documents like new product ideas, previews, or roadmap draft templates. I also collaborate with our marketing team when we create external-facing content like case studies or pitching decks. Analyze competitive intelligence: A dedicated group focuses on market intel. In the software industry, it is hard to be and stay successful if you don't know what your competitors are doing. I share feedback with this group whenever something comes up in a customer meeting or at an event. I read our updated internal documents monthly to learn how to discuss our strategy and product in competitive situations. Present roadmap to customers and prospects: I discuss the company's vision and upcoming features (under NDA) in customer meetings. This is crucial, especially outside the US, where it is much harder for the account teams to get an appointment with colleagues from the US time zone. I cannot go as deep as a product manager. I only share the high-level overview and involve the right product manager in a follow-up with the customer. Internal Enablement of Sales and Marketing In a good company, even the account manager and presales colleagues clearly explain how the own product fits or does not fit into the enterprise architecture of the customer. No one lies and sells products where it is no fit. Though, often this is more of an educational problem. The Field CTO educates internal teams about practical DOs and DONTs. In my case, data streaming is a super complex field. Hence, thought leadership is not just for customers. It is widely used by colleagues, too. For instance, my blog series about data streaming vs. data warehouse and data lake explores how and when data streaming complements other data platforms. Many new hires across business units read this to understand how we fit into the broader data platform market. The Field CTO enables internal teams by demonstrating how to pitch their product's business value and unique selling points. This is crucial for many departments, including sales and marketing. I work with our internal enablement team to incorporate and share my knowledge and experience with new hires. This is not replacing any other internal enablement but is complementary. It adds another perspective. Support Mergers and Acquisitions (M&A) Mergers and acquisitions (M&A) allow enterprises to grow or add new products more quickly and change the nature of their business or competitive position. A Field CTO helps evaluate other companies to guide the M&A team and top management in making the right decisions about buying or not buying the company. The feedback from the Field CTO is about market trends, visibility of the company in the customer base, feedback about the product experience, etc. Task 4: Public Spokesperson I have covered thought leadership and evangelism already. However, being a public spokesperson is very different. A spokesperson is engaged or elected to speak on behalf of others. In the present media-sensitive world, software companies have limited employees who are allowed to speak to the media and analysts. First, you receive formal training in journalism, communications, public relations, and public affairs in this role to ensure that public announcements are made in the most appropriate fashion and through the most appropriate channels to maximize the impact of favorable messages and minimize the impact of unfavorable messages. Being a spokesperson is much harder than doing thought leadership or technical evangelism. Hence, only the very experienced (and responsible) top management announces most critical messages, like the CEO and CFO doing the earning calls in a public company. A CTO or similar colleague announces new product releases. A Field CTO can work as a spokesperson to support: Public relations: Press articles, interviews, statements Analyst relations: Research interviews, presentation of product features and case studies Give Press Interviews and Write Public Articles For public relations, the Field CTO can help significantly in markets outside headquarters. In my case, most interviews and press releases in English are done out of headquarters in Silicon Valley and supported by top management and regional colleagues. I mainly do interviews and press articles for regional events in Europe. The public relations team uses me a lot as a German spokesperson, as I am German. But I also do English press articles, interviews, and podcasts: Contrary to regular blog posts or podcast recordings, the internal communications team reviews (and often even prepares). I collaborate and align with the team to ensure the proper positioning of our products and review the technical content. My broad experience working with so many customers always helps me find the right words, whether an article is for a developer interview or an interview in a CIO automotive magazine. I link my press publications on my website. Educate Research Analysts Like Gartner and Forrester For analyst relations, it is different. While product management is crucial to present our product features and roadmap, I am involved in discussing case studies and industry-related trends. I have meetings and calls regularly with research analysts from Gartner, Forrester, IDG, and others to educate them and provide Q&A from my practical worldwide experience. Working with analysts differs from daily meetings with customers or partners. These research companies don't care only about the technology but about the success stories and the solved pain of customers. I guess everyone has seen a Gartner Magic Quadrant or Forrester Wave. People underestimate that these papers do not just evaluate the product portfolio but the vendor itself. The current product portfolio is essential, but the future product vision, continuous customer support of the vendor, and in the end, customer success and happiness are as necessary for the analysts. In What Business Unit Is a Field CTO? That's a brilliant question. There is no logical answer. I can only talk about myself. During most of my career, I was in "special groups" that have different quarterly goals (often hard to measure in $$$ and quota) and rules (like travel restrictions). My daily job is very flexible and differs every single week. My priorities can change from quarter to quarter depending on new prioritization, regional re-organizations, changes in the competitive market, and so on. I love it. But it does not fit into a standard sales, marketing, or engineering job role (with all its processes and rules). Most importantly: As Field CTO, I do not directly report to a sales or engineering manager. I work in a dedicated innovation group. That enables independent (but aligned) working on my tasks. Other companies might put the Field CTO role into another business unit. It does not matter as long as you can fulfill your tasks the right way. But I could see conflicts if I directly report to a sales or marketing manager. Why This Job Title? The title Field CTO is coming up more and more in software companies. It is often used because some people in the company need a clear, visible description of their tasks. Many people use this term because there is no better one, and the role (maybe) did not exist in the past. There are plenty of other job titles. Chief evangelist? Global technology advisor? Distinguished XYZ? I feel these titles make little sense and do not clearly say what I am doing. Hence, like data streaming or cloud-native data warehouses define new software categories, the job role of the Field CTO creates a new category. Let's review this in 2, 5, and 10 years... Is It a Management Role? No. Field CTO is NOT a people management role. My management asked me tens of times if I wanted to get management responsibility and lead other colleagues. The clear answer was always a rapid "no!"... I am very good at thought leadership in technology and innovation, creating public content, talking to different kinds of people in small and big audiences, and collaborating with customers and colleagues around the world. But I am not interested in managing other people. If you look at my long list of tasks, you quickly realize there is no time for this. Where Is the Headcount on Indeed, Glassdoor, LinkedIn, Etc.? You often don't find enterprises directly searching for this role. And frequently, it has a different name, as the title was just being created in the industry for a few years. There is no standard definition for a Field CTO like a sales rep, presales, field marketing, or software engineer. Sometimes, the Field CTO is an informal role, not an official headcount. Your Workday might still say you are a distinguished software developer, principal presales, or similar. But you still use Field CTO in your internal and public profile. Search for "Field CTO" in quotation marks (otherwise, you will only find CTOs - a very different and much more frequent job role). If you want to see a few other job descriptions and the career histories of Field CTOs, first check my Linkedin profile. Then search for "Field CTO", and you will find several people from software companies. For instance, my search shows connections from Snowflake, Databricks, VMware, MuleSoft, Tableau, and others. Field CTO is a new job role getting more and more traction. Other Field Ctos in the Software Industry This blog post is a story about my daily life as Field CTO. My personal definition of the job role of Field CTO in one sentence: The Field CTO is a trusted and well-known advisor for the product and technology my employer sells to make customers successful around the world. As discussed in this blog post, the role is very individual and can look very different in other business units or organizations. Hence, I also want to share a few of my fellows from other software companies so that you see a few more examples that are similar and different at the same time: Daniel Hand, Field CTO APJ, Cloudera: A senior technology leader building and leading teams within disruptive, high-growth technology companies. "As a Field CTO, I help guide organizations to become increasingly data-driven through the adoption of Cloudera’s Enterprise Data Cloud." He is also a published author and contributor to O’Reilly Media and Addison-Wesley. Fawad A. Qureshi, Global Industry Field CTO, Snowflake: Fawad is a strategic technology leader with more than two decades of international industry project experience involving consulting on enterprise data warehouses, big data analytics, and cloud solution architectures. He helps customers in multiple industries to translate their business requirements into technology solutions. He is passionate about sustainability and helps his clients achieve their sustainability goals using data and analytics. Jeroen Reizevoort, Field CTO EMEA, MuleSoft (Salesforce): Inspires customers by aligning their business initiatives to technology trends and helping them to make that combination actionable. "I am a technical executive responsible for communicating the corporate direction and product roadmap to regional customers’ business and technology leaders, as well as influencing the corporate and product strategy through industry expertise and synthesized field input." Stephen Walters, Field CTO, GitLab: Works with customers on DevOps initiatives to the development lifecycle. He is a subject matter expert with management and consultancy experience across end-to-end IT disciplines. "As a Field CTO, I am always looking at emergent areas of business and technology. A key area at the moment is value stream management." His job role includes being a keynote speaker on specialist subjects at conferences and webcasts and publishing articles. Liz Fong-Jones, Field CTO, Honeycomb.io: Promoted from Principal Developer Advocate to the Field CTO role. She blends hands-on technical experience as a member of Honeycomb's platform rotation, pairing with customers on implementation and articulating the business value of observability to leadership and executives. She's a frequent keynote speaker and author of Observability Engineering, published by O'Reilly Media. How To Become a Field CTO Many people ask me how they can get a job similar to mine. They see how many things I do, where I travel, and what lessons and case studies I share. That's very exciting and attracts many people. What previous job positions should you have had to become a Field CTO? A customer-facing role is critical. Ideally, you mix different experiences like developer relations, consulting, and technical sales (aka presales). Here is how I would define the critical criteria for becoming a Field CTO: Talent: Mix of many things (tech and non-tech skills) Experience: At least 10+ years with different companies, technologies, industries, regions, etc. Curiosity: Learn something new every day across many (tech and non-tech) topics Travel: Meet customers/prospects/partners/community/colleagues everywhere in your region or even worldwide Talent is likely the most challenging part, as you cannot learn everything. If you are unable (or don't enjoy) speaking to different personas (like CIO, business person, developer), this job is impossible. You must also work with many people with very different opinions and fight against your thought leadership. Experience is about broad knowledge across many topics. Technology is vital, but there is so much more. You must understand internal and external processes, sales cycles, cultures, regulations, etc. Curiosity is mandatory, as you will (have to) learn new trends and innovations before most people even think about it. And compare and integrate it with existing technologies and platforms. It is not just about "why change" but an evolution of your customers, not a "big bang". Travel is the hardest part for many people. If you cannot travel regularly (at least in your region), forget it. Yes, things go virtual. But like many tasks of executives and top management, the functions of the Field CTO need interaction with humans. Meeting customers on-site in critical meetings or sharing case studies in roundtables only works well in person. And each region is different. Did covid change travel? No. Not for the role of the Field CTO. Instead, it showed me how important and valuable on-site meetings are. Field CTO Is a Critical Position in a Software Company The broad spectrum of tasks allows a Field CTO to leverage the unique capabilities for internal and external thought leadership and knowledge sharing. The success of the customers is the ultimate goal of every employee of a company. Collaboration with various internal teams, partners, customers, and the community is essential. The combination of continuous learning and knowledge transfer makes a good Field CTO. Curiosity combined with the human factor of 1-1 conversations in a variety of contexts is the secret sauce. What are your tasks as a Field CTO? Or, if you want to grow into that role, what is your current job role and strategy for the future? Let’s connect on LinkedIn and discuss it! Join the data streaming community and stay informed about new blog posts by subscribing to my newsletter.
As software engineers, we mainly talk about the power of tech skills and spending time learning new techniques. However, there is also the matter of influence that impacts your career as well. Why Should I Care About Influence? Usually, we only focus on the hard skill when discussing the software career path. That is a colossal mistake that several engineers, including me, have committed for a long time. In this post, I'll explain why influence is vital to your career. The first step on this post is to ensure we're on the same page. The discussion here is not to undervalue the tech perspective. Any engineer must have experience with software engineering, architecture, code design, and so on. The point is not to focus only on those aspects and forget the others. We mainly consult communication when discussing the post-senior career path, such as a Staff-Plus Engineer. The Staff Engineer's Path book by Tanya Relly explains how to get on the culture/organization map, mainly the trick terrain. Also, it includes the relationship between the engineering and product teams. The Tanya Relly book is an excellent book that contains the importance of influence, but this is not unique. There is also the Engineers Survival Guide: Advice, tactics, and Tricks, which has a chapter called "Influence Is Everything." This book was one of the first I read about branding for a software engineer. Being visible inside and outside the organization is crucial for your career. I hope I got your attention to how vital visibility is for any engineering career. Let's talk about how to raise your visibility inside and outside the organization. Let's start to apply it. Increasing Your Visibility When we discuss, visibility is vital to highlight that you need to be visible to both inside your organization and outside. When your organization knows what you know and what you're doing, it becomes easier to talk about your internal progress and promotion. However, the career belongs to you and not your company. With that in mind, find ways to work on your branding outside the organization. Sadly, some companies do not value you, and you need to be prepared to move, and when you have visibility around what you're doing, it becomes more accessible to archive a new job. In this post, we'll enumerate four options: Explore the company blog: Your company blog is an excellent place to share your status, share good practices, and help your colleagues in a single place. Team scalability and raising the quality bar are other points you can address using this place. Be kind: Everyone enjoys an accessible and helpful person; this is not an exception in an organization. Be prepared to help other colleagues with your knowledge, and be available to help. You're not scalable; thus, define a strategy to impact the most people possible with internal workshops, articles, and mentoring other engineers. Conferences: A conference is a place not only to share your knowledge and your expertise, but also learn and increase your networking. There are several options for meetings, such as in-person and online. Explore both because human contact is essential, and your new contact might be your following colleagues, but online is a time-saver on conferences. Use the time to get more people in your circle. Open source: It is only possible to talk about the ultimate stage of sophistication in software engineering by talking about open source. Being part of big open-source projects such as Inside Eclipse and Apache Foundation can help you learn the most advantageous technique to enhance your engineering team. From open source, you can learn from several companies to archive high-quality code, comprehensive documentation, strong collaboration, and a healthy culture. Besides this knowledge, open source will help visibility. This is differential; e.g., the number of people who contribute to JVM or Java language is less than the person who works with Java. Conclusion As software engineers, we usually talk only about hard skills; however, the influence matters in your career. Getting visibility inside and outside the organization is crucial. It is time to discuss more the branding and your credibility. There are several ways to increase this credibility, such as company posts, personal posts, conferences, open source, and more. I hope I helped you see this perspective and move your career to the next level. Please let me know your thoughts, if you're investing your time in being visible, and which methodologies you're doing.
A geek programmer acquires technologies like shiny tools in a utility belt. But every technology is simply a collection of patterns expressed in a language, and most patterns are not new; if we understand the patterns, we can readily understand any technology that embodies them. At various times in my life, I’ve geeked out on programming, but I don’t think that’s the hallmark of a good developer. What could be wrong with a talented developer who gives 110% creating clear, accurate maintainable code from 9 to 5, enjoys lunch while talking about anything but work, and goes home to a life unleashed from a keyboard? Here are what I think are the five key competencies of a developer. To see why they are important, think about what software is: it’s not an endless series of statements, nor a collection of arbitrary calls to an API, nor is it only cut-and-paste. Instead, it’s a network of hierarchies of code—highly structured, with little copied code—mainly replicated patterns (not necessarily the GOF patterns but ones like “lazy initialization,” “model-driven code generation,” or “scripting in XML”). It’s also only useful if it meets business requirements and is of adequate quality. So, we need to assess the skills that enable a developer to meet these goals. Enough preamble; let’s go. 1. Analytical: Structured, Clear, Critical Thinker, and Problem Solver The problem is that a lot of people mistake poise, confidence, or rapid continuous speech for intelligence. So, we need to be very clear about the hallmarks of intelligence for a developer. Software is all about functional and structural decomposition, so I think the key aspect of intelligence is to be analytical by nature, nurture, or force of will. An analytical person will consider a question or problem from multiple angles, choosing the best general approach and then breaking the problem down into sub-problems. You can detect this competency in an interview quite easily because the candidate will naturally seek to clarify an ambiguous question or list the parts and relationships of a solution or “top and tail” a problem to identify its scope before going into details. To detect this competency, you don’t have to give them a new problem, just ask them to describe almost anything: a software product they worked on, object orientation, the roles or process of software development, the internet, web, or equally the layout of a real, or ideal city, the nature of democracy, the definition and operation of evolution, etc. When the description is complete, ask yourself if you have heard an enumeration of the pieces or if the candidate has described the heart of the matter; that’s analytical. 2. Abstract: Capable of Identifying and Understanding Abstractions and Patterns Software is complex; you cannot understand it by simply reading every line of code. You understood it by looking for structure, building a theory of how the code is modeled, and then verifying and changing that model as you read. Developing new software is a lot like understanding an existing program, except that the model does not yet exist, only the “theory” of that software in your mind. Your program expresses the theory in the model of code. If you think in terms of abstractions, writing a functional or technical specification is not that different from coding, except that the language is a human one, and the interpreter will be one or more human minds. A specification is abstract because no program can run it, but if it is accurate, complete, clear, and well-structured (all qualities we seek in code), then a developer can implement it. 3. Precise: The Ability To Express Something Concisely and Accurately Some developers manage to be somewhat successful by only replicating examples; they look for something close to what they want to implement and then tweak it. This is like sculpting, except when it is done with code, the result is usually not very clear, not very concise, and probably not entirely accurate. Similarly, some developers can only explain things by example, not by naming the underlying concepts or patterns. This is acceptable but will be a stumbling block because they are less likely to recognize, understand, and apply patterns at the micro or macro level in code. A developer who can be precise (but not necessarily rapid or impressive) in speech will develop more precise code and more easily explain a technique or a requirement to another developer. 4. Prioritized and Pragmatic: The Skill of Recognizing What Must Be Done Versus What Could Be Done The agile approach naturally favors writing today’s code today. Even in companies that do waterfall development, it is still a vital skill to be able to distinguish between the essential and the possible. Products are often only entirely successful by being delivered on time. A pragmatic developer does what’s needed, creating a few hooks and writing the comments that lay the groundwork for tomorrow. Pragmatism is also demonstrated by the desire to achieve, complete, and finish; this drives and encourages us to define what is success, helps us prioritize the way to get there, and focuses on the completion of tasks rather than on gold-plating. 5. Idealistic: The Desire To Do Things Right A developer who is only pragmatic can sometimes be lazy; not only do they only develop today’s functionality, but they only code for today, not for the developer who has to maintain that code tomorrow. An idealistic developer actually cares about all the qualities of what they deliver: They ensure they understand the requirements. They consider and possibly even document the test cases before they write a line of code. They write code that is clear and adequately commented; they continuously refactor, so that common code moves into shared methods and then into base or helper classes. They write unit test cases to protect other developers and testers from bugs. They consistently do manual testing where an automated test is impractical. Idealism and pragmatism are necessary counterparts, balancing and informing the decisions a developer makes all day long. Other Competencies Naturally, there are other competencies: Concentration: writing software is a complex task of transcribing a model of the mind into code. The ability to understand and use technologies. The desire to learn and improve all the skills they need to be effective individually and as part of a software delivery organization. The recognition that their skills are often meaningless unless they mesh with the other roles on their team and other teams. Conclusion One final competency; however, is one that we all need; the ability to recognize that there is no uniquely valuable set of skills or behaviors. In any organization, there are multiple ways to be successful, many roles to fill, and an individual’s work is just part of a larger process, all of which needs to work to be successful. Smart people sometimes overlook other kinds of intelligence; it helps if we maintain the desire to achieve mutual respect and offer our views as an opinion, even if we believe we are correcting an error—you’d be surprised how often we confuse opinions and perspectives as facts. However, a developer would do well to have the competencies above; then they are well placed to advance in their career on the technical track to become a senior developer, then a development lead and later an architect, or on the management track where integrity, a passion for respect, and the desire to inspire and help others to achieve are even more key.
In a Nutshell We instinctively equate programming with writing code. Because of it, we focus primarily on code design and creation skills: mastering languages and frameworks, clean code, design patterns, TDD, and architecture. But creating new code is only a fraction of what we do every day. For example, we spend much more time navigating, searching, analyzing, reviewing, and debugging code than writing. Though these activities seem straightforward, they require as specialized skills and experience as coding. Mastering them is what separates true senior programmers from the crowd. And what makes you stand out and get noticed at a new job. In this post, I'll look at the key traits of professional software development, how they impact what you do every day, and explore what skills you need to become a complete programmer. The Common Misconception About Programming People instinctively equate programming with writing code. And it doesn't apply only to lay people. But, unfortunately, many experienced programmers also do have this bias. Not in a naive way, of course. We know that coding isn't just typing and that having crazy keyboard skills doesn't make you a great programmer. But even then, we focus mainly on code creation skills. Think for a moment about what most books, blog posts, and talks are about. What sparks the most heated discussions in your team? What are the most common coding interview questions? Clean code. Deep, almost arcane knowledge of programming languages and frameworks. Design patterns. Architecture. Algorithms and data structures. Writing beautiful unit tests. Those are fundamental skills, yes. But they still focus mostly on code creation. I'm not saying these skills aren't important. They are critical for a senior developer. And there's so much depth there that they can be studied for years. But they cover only a small fraction of what we do every day. And focusing only on code creation skills while neglecting the rest will make you a very incomplete and ineffective programmer. To call yourself a true senior programmer, you need a well-rounded skill set. But to develop this skill set, you first need to acknowledge what actually defines how we work. What Professional Software Development Really Looks Like Professional software development has a few traits which have a profound impact on what we do every day as programmers: 1. Software Development Is a Team Activity, and Most of the Software Is Long-Living What this means in practice is that the majority of the code you'll work with was either written by someone else, modified by someone else since you wrote it, or written by you sufficiently long ago to forget it. It also means that most of the code you'll work with will be legacy. 2. Humans Are Prone to Mistakes No matter how experienced you are, how rigorous is your process, and how clean and modular is your codebase, you'll still introduce errors. And a lot of them. They may not (hopefully) land on production if your Quality Assurance process is tight, but during local development, you'll have to constantly cope with bugs. 3. Modern Software Stacks Are Too Complex to Learn Everything by Heart The number of technologies, the surface area of all the APIs, and the pace of updates are simply too high. Even if you are a seasoned programmer, working for years with one stack, it's impossible to just continuously write code without pausing to look stuff up. 4. Commercial Software Is Built Under Tight Time and Resource Constraints So unless it's your personal hobby project, you'll constantly be struggling to balance cutting corners (to generate business value faster) and keeping the codebase healthy (not to cannibalize your long-term performance). 5. Understanding a New Codebase Quickly Is a Critical Career Skill In a new job, your first impression sets up how you'll be seen for a long time (if not forever). And it depends on how fast and self-sufficiently you can find your way around the new codebase. If you are able to start meaningfully contributing right off the bat without much guidance, you'll be immediately perceived as a strong senior. When you look at the above five traits, you can clearly see that your most important skills are the ones related to reading, analyzing, and reviewing code, navigating unknown code bases, debugging, finding information, and being able to walk a thin line between under- and over-engineering. But let's explore these skills more in-depth. What a Well-Rounded Developer MUST Be Skilled At Exploring and Understanding New Codebases (a.k.a. Code Archaeology) Mapping the lay of the land. "Reading" the overall layout of the codebase (directory structure, architectural layers, main business domains) and building a mental model of the flow of data and logic through the application. Knowing how to efficiently map, diagram, and visualize the code, data, and flow. Navigating and searching the code. Using the full power of your IDE to efficiently find your way around the codebase: navigate up and down component or inheritance hierarchy; navigate up and down function or method call chain; look up the definition of the function, class, component, or constant; look up the dependencies of a class, function, or component; find all the occurrences of a class, function, or variable; quickly switch between code and related tests; quickly find component, class, function, or constant by name. BONUS: knowing how to structure the codebase and name stuff to make it easily navigable. Exploring the Git history. Effectively navigating through the commit and pull request history to understand the context and the decisions behind the current state of the code. Using tools like git blame to identify where to find the necessary information. BONUS: writing good commit and pull request descriptions that will make exploring Git history easier for other developers. Exploratory testing and code inspection. Using manual and automated end-to-end exploratory tests to see how the application works (which is often hard to understand from the source code alone). Stubbing API requests with fake data to get the application into the desired state to explore all the edge cases. Peeking into the application's inner workings by the means of characterization unit tests, debuggers, and inspection tools (web browser dev tools, interactive shells, request capturing tools like Postman, etc.). Debugging Understanding the overall debugging principles and approaches. Top-down vs bottom-up debugging. Divide and conquer approach. Tradeoffs of using different approaches to pinpoint the problem (for example, debugger vs. "print" statement). What input data to use to most efficiently replicate the bug, and at what level to insert this data: UI, web requests, or somewhere inside the code. Debugging and inspecting the code. Deep knowledge of the whole range of debugging tools and approaches: integrated and external debuggers, "print" statements and equivalents like browser's console.log, in-code assertions, using unit tests to debug the code, using git bisect. Deep knowledge of the tools to inspect and interact with the running application: browser dev tools, your framework dev tools (for example, React or Redux dev tools), interactive shells, tools like Postman to capture and inspect API requests, and so on. Interpreting and following error messages. Knowing the most common error messages of your language and framework. Understanding how they are formatted and what additional info they contain. Tracing error messages to the actual place in the source code (knowing how to interpret stack traces, using tools like source maps, and so on). Looking up less common error messages. Monitoring and logging. Using server and cloud platforms' logs to detect and triage errors. Using log management and visualization tools like Grafana, Kibana, or Splunk to pinpoint errors easier. Utilizing monitoring tools like Sentry, AppSignal, or NewRelic. Reviewing Code Understanding the context. Discerning what the original code does and what the change was intended to do. Building a mental map of what exactly was changed and how it impacts the workings of the app. Using tools like your IDE, Git command line, and Git UIs to effectively navigate code and diffs to understand the changes and their context. Understanding what to focus on. Which changes are critical, and which ones are cosmetic? Which will impact code security, architecture, readability, and long-term maintainability, and which ones are more a matter of personal taste (and should be left to the pull request author). What requires human analysis, and what can be left for linters and code formatters? Efficiently reviewing (and re-reviewing) the code. Efficiently navigating through the changes and the discussion (other reviewers' suggestions, pull request author's replies). Understanding how to most effectively review a PR depending on its size, complexity, and quality of individual commits (if it should be reviewed commit-by-commit or all the changes altogether, etc.). Utilizing more advanced features of your code hosting platform like GitHub's multi-line comments or suggested changes. Effectively re-reviewing fixes applied by the code author to your (and other reviewers') suggestions. Collaborating with the author and other reviewers. Writing constructive, non-aggressive, easy-to-understand suggestions that are helpful to the pull request author and the rest of the team. Clearly distinguishing the "must-fix" suggestions from the "for-the-purpose-of-the-discussion" ones. Knowing when to press and when to step back, and when and how to gracefully end the discussion. BONUS: Making your pull requests easy to review. Writing great pull requests and commit descriptions. Knowing how to make a pull request easier to review: when to do one bigger commit vs. multiple smaller ones, what should be the pull request boundaries, and so on. Finding Information Having a good understanding of the documentation for your stack of choice (how is it organized and how to most efficiently find what you need). Getting good at looking up stuff on the internet (Google, StackOverflow, etc.). Using the full power of your IDE: inline documentation, parameter hints, go to definition, and so on. Working With Legacy Code Understanding technical debt. Understanding the tradeoffs between under- and over-engineering: which debt is worth paying off right now, later, and never; which should be paid off gradually and which as a one-off, bigger project. Setting boundaries of what should be paid off in the current batch. Understanding how to work during the transition period when paying tech debt gradually. Isolating legacy code and covering it with a safety net. Identifying natural boundaries ("seams") to isolate areas of legacy code for controlled, limited changes. Covering the isolated area with the temporary characterization tests at the seams to provide a safety net against the regression during refactoring. Converting characterization tests to the properly focused unit tests after refactoring. Restructuring and refactoring the old code. Knowledge of refactoring patterns and techniques (especially extracting and modularizing the code to contain the scope of the refactoring). Using your IDE, code mods, linter auto-fix, and similar automated refactoring tools. Bottom Line If you want to advance your career, you have to be a complete package. Code archaeology, debugging, reviewing code, finding information, and working with legacy code, are absolutely critical skills to have (especially as a complete bundle, as they interact and reinforce each other). Not only you'll spend more time on these activities than on the actual code creation, but they will also enhance your creative skills. And they are what screams "true senior" to your colleagues and managers.
Continuous learning is one of the guiding principles that all people should apply in their life. Reading is an excellent tool to learn, and it is a habit that we should all be doing on a regular basis. Since I love reading books about different topics, in this article, I'm going to share five books that have helped me a lot to improve as Engineering Manager. When we read a book, we should always remember three important things: Authors are sharing their knowledge, thoughts, or experiences based on their context or culture. These factors may be different from ours. The same book provides different values and learnings to each reader for the same reasons. Each reader has a different context, culture, habits, and previous knowledge. Books and methodologies provide guidance that helps us to improve, but they are not our owners. We must take what makes us better, adapt what does not fit, and especially think for ourselves in order to make decisions based on our context. Now let's go to the books that have helped me to better myself. Five Books That Have Helped Me Become a Better Manager The Manager's Path This is my favorite book about engineering management. In my opinion, it provides a clear vision of the Engineering Manager's roles. In my case, it reinforces some of my ideas and provides valuable information about some aspects that needed to be improved, such as 1-2-1 and performance reviews. The following topics were addressed: 1-2-1 and performance reviews Continuous feedback Mentoring How to manage people in different scenarios How to manage a team Managing managers If you are or want to be an Engineering Manager, you can't miss this book. The Goal: A Process of Ongoing Improvement This is a book written in 1992 that is about the optimization of production in a manufacturing factory. It is a great book that gives us a vision of how to manage and optimize a company based on the theory of constraints and work in progress (WIP). It is a book written in a novel format that provides you with knowledge through a suspense story. There is another book based on this that is focused on an IT department, The Phoenix Project: A Novel About IT, DevOps, and Helping Your Business Win. I like these books because they project a journey in which they describe emerging issues, new challenges, and complex situations closer to the reality of what will be your career as an Engineering Manager. Team Topologies: Organizing Business and Technology Teams for Fast Flow It focuses on how to set up a dynamic team structure and interaction modes that can help teams adapt quickly to new conditions and achieve fast and safe software delivery. It provides valuable and clear information for understanding an IT structure and its interaction. Some of the points he describes you will already know, but it will help you to understand them better: Conway's Law with practical examples Three different organizational structures in every organization: Formal, informal, and value creation Four fundamental team topologies: Stream-aligned, Enabling, Complicated-subsystem, and platform The Obstacle Is the Way: The Timeless Art of Turning Trials into Triumph It is a book based on stoicism. Engineering Managers usually feel a lot of frustration generated by the management of uncertainty, emerging jobs, and multiple obstacles that appear in their day-to-day work. Sometimes we are more focused on what we cannot control and a misperception of situations. This book helps us to focus on the things we can control, let go of everything else, and turn every new obstacle into an opportunity, handle defeat and difficulty. We will learn how to deal with obstacles and how to react appropriately so that they do not hold us back. The Software Architect Elevator: Transforming Enterprises with Technology and Business Architecture It is a book that I recommend for both architectural and management roles. These two roles have many things in common. This book helps us to understand that a company is like a building with several floors, in which, on each floor, there are people speaking different languages and probably going in different directions. We will hear how an architect should ride an elevator up and down to talk with people on different floors to align them to go in one direction. Supporting the business strategy, connecting the dots, and avoiding over-engineering. This ability to communicate at different levels, simplification capacity, and alignment are capabilities that Engineering Managers must also have. What about technical books? Conclusion To support our teams to achieve their objectives, we must have knowledge of different areas and also understand the context of the company. These books provide information on five key aspects: people management, IT structures, company and process optimization, communication at different levels, and how to make a journey full of obstacles.
Author, Researcher, Speaker, Director, DevOps Enthusiast,
VP of Engineering,
Jade Rubick Consulting LLC