Despite its hefty $1.3 billion investment, the recent collapse of Inflection serves as a stark reminder of the volatile AI startup landscape. Inflection’s flagship product, Pi, a ChatGPT rival, failed to gain traction, leading to the company’s dismantling by Microsoft. This case exemplifies the broader trend of massive capital influx into AI ventures lacking substantial products.
The Rise and Fall of Inflection
Inflection was founded by notable entrepreneurs such as Mustafa Suleyman of DeepMind, Karén Simonyan, and Reid Hoffman. Suleyman, a co-founder of DeepMind, had previously contributed to its advancements in AI, which eventually led to its acquisition by Google. Simonyan brought extensive experience from his work on AI research, while Hoffman, co-founder of LinkedIn, provided substantial entrepreneurial and investment acumen.
With backing from influential investors including Bill Gates and Eric Schmidt, Inflection aimed to create a more empathetic AI companion. The company took around two years to develop Pi, its primary product, hoping to leverage its founders’ reputations and the significant capital raised to break into the AI market.
Why Pi Failed
Pi’s failure is attributed to several factors:
Lack of Unique Value: Pi’s context window was significantly shorter than competitors, hindering its ability to provide sustained conversational quality.
Market Oversaturation: The AI companion market is fiercely competitive, with established players like ChatGPT and Character.ai leading the pack.
Financial Mismanagement: Heavy investment without a corresponding viable product highlighted the risks of capital-heavy ventures in AI.
AI Funding and Startup Failures
The AI sector saw an estimated $50 billion in investments in 2023 alone. However, many startups have failed to deliver on their promises. Some notable closures in the last 18 months include:
Inflection: Absorbed by Microsoft, ceasing independent operations.
Vicarious: Acquired by Alphabet, failing to achieve its goal of human-like AI.
Element AI: Acquired by ServiceNow after struggling to commercialize its research.
Startup
Total Investment ($M)
Years to Product Launch
Peak Annual Revenue ($M)
Outcome
Inflection
1300
2
5
Acquired by Microsoft
Vicarious
150
4
2
Acquired by Alphabet
Element AI
257
3
10
Acquired by ServiceNow
MetaMind
45
2
1
Acquired by Salesforce
Geometric Intelligence
60
1
0.5
Acquired by Uber
The Future of AI Investment
This trend of high investment but low product viability raises concerns about the future of AI innovation. Consolidation around major players like Microsoft, Google, and OpenAI could stifle competition and limit diversity in AI development.
Conclusion
The downfall of Inflection underscores the precarious nature of AI investments. As the industry continues to grow, investors must prioritize viable, innovative products over mere potential. This shift could foster a more sustainable and dynamic AI ecosystem.
Non-Compete Clauses: FTC’s Influence on Tech Innovation & Employee Freedom
The recent FTC ruling banning most non-compete agreements nationwide has ignited a firestorm in the business world. While some cheer the increased freedom for workers, others fear a potential talent exodus and a decline in innovation. Let’s delve deeper into this debate, exploring the arguments for and against non-compete clauses, along with the potential consequences of the ruling.
Champions of the Free Agent: A Rising Tide Lifts All Boats
Proponents of the FTC’s decision paint a rosy picture. They argue that:
Increased Worker Mobility: With non-compete shackles removed, workers can freely pursue more lucrative opportunities. This competition between companies drives salaries upwards, forcing employers to offer competitive benefits packages to retain talent.
Innovation on Steroids: A more mobile workforce fosters a cross-pollination of ideas. Employees bring fresh perspectives and experiences from previous roles, leading to a more dynamic and innovative environment across industries.
Empowering the Underdog: Critics of non-competes argue that these clauses disproportionately affect low-wage workers. They often lack the resources to challenge them in court, effectively becoming trapped in jobs with limited upward mobility.
The Employer’s Lament: Protecting the Crown Jewels
Companies are understandably nervous about the FTC’s ruling. Here’s why:
Trade Secrets at Risk: Businesses worry that departing employees, especially those privy to sensitive information, might jump ship to a competitor, potentially taking valuable trade secrets with them. This could give a rival an unfair advantage and stifle innovation.
Customer Loyalty on the Move: Companies also fear losing established customer relationships when key salespeople or account managers move on to a competitor. This could lead to a decline in customer retention and revenue.
Poaching Wars: A Race to the Bottom: Without non-compete clauses, some companies worry about fierce “poaching wars” erupting, where competitors aggressively recruit talent and drive up salaries for specific roles. While this might benefit a select few employees, it could negatively impact smaller companies with limited resources.
The Nuance: Not All Non-Compete Clauses Are Created Equal
It’s important to acknowledge that the FTC ruling has some limitations. Here are some potential grey areas:
Executive Contracts: The ruling may not apply to high-level executives whose contracts often contain stricter non-disclosure and non-compete clauses. These agreements might still be enforceable depending on specific terms.
State Variations: While the FTC ruling aims to be a blanket policy, some states might have stricter or more lenient regulations regarding non-compete clauses. Employers and employees should be aware of their state’s specific laws.
Industry Specificity: The FTC ruling might have a more significant impact on specific industries like tech, where knowledge transfer and trade secrets are particularly valuable. Other sectors may be less affected.
The Future of Work: A Brave New World?
The FTC’s ruling is a major turning point that could significantly reshape the American workforce. It’s too early to predict the full impact, but some potential scenarios include:
Rise of the Free Agent Economy: Highly skilled workers with in-demand expertise may become more like free agents, negotiating short-term contracts or project-based work with various companies.
Focus on Retention Strategies: Companies may shift their focus towards creating a more positive work environment that fosters loyalty and discourages employees from leaving. This could include better benefits, training opportunities, and a strong company culture.
Increased Use of Confidentiality Agreements: Non-compete clauses may be replaced by stricter confidentiality agreements to protect sensitive information, although their enforceability might vary.
Some say that NoOps is the end of DevOps. Is that really true? If you need to answer this question, you must first understand NoOps better.
Things are moving at warp speed in the field of software development. You can subscribe to almost anything “as a service” be it storage, network, computing, or security. Cloud providers are also increasingly investing in their automation ecosystem. This leads us to NoOps, where you wouldn’t require an operations team to manage the lifecycle of your apps, because everything would be automated.
Picture Courtesy: GitHub Blog
You can use automation templates to provision your app components and automate component management, including provisioning, orchestration, deployments, maintenance, upgradation, patching and anything in between meaning significantly less overhead for you and minimal to no human interference. Does this sound wonderful?
But is this a wise choice, and what are some advantages and challenges to implementing it?
Find out the answers to these questions, including whether NoOps is DevOps’s end in this article.
NoOps — Is It a Wise Choice?
You already know that DevOps aims to make app deployments faster and smoother, focusing on continuous improvement. NoOps — no operations — a term coined by Mike Gualtieri at Forrester, has the same goal at its core but without operations professionals!
In an ideal NoOps scenario, a developer never has to collaborate with a member of the operations team. Instead, NoOps uses serverless and PaaS to get the resources they need when they need them. This means that you can use a set of services and tools to securely deploy the required cloud components (including the infrastructure and code). Additionally, NoOps leverages a CI/CD pipeline for deployment. What is more, Ops teams are incredibly effective with data-related tasks, seeing data collection, analysis, and storage as a crucial part of their functions. However, keep in mind that you can automate most of your data collection tasks, but you can’t always get the same level of insights from automating this analysis.
Essentially, NoOps can act as a self-service model where a cloud provider becomes your ops department, automating the underlying infrastructure layer and removing the need for a team to manage it.
Many argue that a completely automated IT environment requiring zero human involvement — true NoOps — is unwise, or even impossible.
Maybe people are afraid of Skynet becoming self-aware!
NoOps vs. DevOps — Pros and Cons
DevOps emphasizes the collaboration between developers and the operations team, while NoOps emphasizes complete automation. Yet, they both try to achieve the same thing — accelerated GTM and a better software deployment process. However, there are both advantages and challenges when considering a DevOps vs. a true NoOps approach.
Pros
More automation, less maintenance
By automating everything using code, NoOps aims to eliminate the additional effort required to support your code’s ecosystem. This means that there will be no need for manual intervention, and every component will be more maintainable in the long run because it’ll be deployed as part of the code. But does this affect DevOps jobs?
Uses the full power of the cloud
There are a lot of new technologies that support extreme automation, including Container as a Service (CaaS) or Function as a Service (FaaS) as opposed to just Serverless, so most big cloud service providers can help you kickstart NoOps adoption. This is excellent news because Ops can ramp up cloud resources as much as necessary, leading to higher capacity, performance & availability planning compared to DevOps (where Dev and Ops work together to decide where the app can run).
Rapid Deployment Cycles
NoOps focuses on business outcomes by shifting focus to priority tasks that deliver value to customers and eliminating the dependency on the operations team, further reducing time-to-market.
Cons
You still need Ops!
In theory, not relying on an operations team to take care of your underlying infrastructure can sound like a dream. Practically, you may need them to monitor outcomes or take care of exceptions. Expecting developers to handle these responsibilities exclusively would take their focus away from delivering business outcomes and wouldn’t be advantageous considering NoOps benefits.
It also wouldn’t be in your best interest to rely solely on developers, as their skill sets don’t necessarily include addressing operational issues. Plus, you don’t want to further overwhelm devs with even more tasks.
Security, Compliance, Privacy
You could abide by security best practices and align them with automatic deployments all you want, but that won’t completely eliminate the need for you to take delicate care of security. Attack methods evolve and change each day, therefore, so should your cloud security controls.
For example, you could introduce the wrong rules for your AI or automate flawed processes, inviting errors in your automation or creating flawed scripts for hundreds or thousands of infrastructure components or servers. If you completely remove your Ops team, you may want to consider investing additional funds into a security team to ensure you’re instilling the best security and compliance methods for your environments.
Consider your environment
Considering NoOps uses serverless and PaaS to get resources, this could become a limiting factor for you, especially during a refactor or transformation. Automation is still possible with legacy infrastructures and hybrid deployments, but you can’t entirely eliminate human intervention in these cases. So remember that not all environments can transition to NoOps, therefore, you must carefully evaluate the pros and cons of switching.
So Is NoOps Really the End of DevOps?
TL:DR: NO!
Detail: NoOps is not a Panacea. It is limited to apps that fit into existing #serverless and #PaaS solutions. As someone who builds B2B SaaS applications for a living, I know that most enterprises still run on monolithic legacy apps and even some of the new-gen Unicorns are in the middle of Refactoring/Migration which will require total rewrites or massive updates to work in a PaaS environment, you’d still need someone to take care of operations even if there’s a single legacy system left behind.
In this sense, NoOps is still a way away from handling long-running apps that run specialized processes or production environments with demanding applications. Conversely, operations occur before production, so, with DevOps, operations work happens before code goes to production. Releases include monitoring, testing, bug fixes, security and policy checks on every commit, etc.
You must have everyone on the team (including key stakeholders) involved from the beginning to enable fast feedback and ensure automated controls and tasks are effective and correct. Continuous learning and improvement (a pillar of DevOps teams) shouldn’t only happen when things go wrong; instead, members must work together and collaboratively to problem-solve and improve systems and processes.
The Upside
Thankfully, NoOps fits within some DevOps ways. It’s focused on learning and improvement, uses new tools, ideas, and techniques developed through continuous and open collaboration, and NoOps solutions remove friction to increase the flow of valuable features through the pipeline. This means that NoOps is a successful extension of DevOps.
In other words, DevOps is forever, and NoOps is just the beginning of the innovations that can take place together with DevOps, so to say that NoOps is the end of DevOps would mean that there isn’t anything new to learn or improve.
Destination: NoOps
There’s quite a lot of groundwork involved for true NoOps — you need to choose between serverless or PaaS, and take configuration, component management, and security controls into consideration to get started. Even then, you may still have some loose ends — like legacy systems — that would take more time to transition (or that you can’t transition at all).
One thing is certain, though, DevOps isn’t going anywhere and automation won’t make Ops obsolete. However, as serverless automation evolves, you may have to consider a new approach for development and operations at some point. Thankfully, you have a lot of help, like automation tools and EaaS, to make your transition easier should you choose to switch.
The fact that you clicked on this article tells me that you are leading/heading a Team, group or an entire Engineering function and most likely a fast-paced startup. Assume the following,
It was a regular weekday, and your CEO/CTO asked the most intriguing question.
Do we measure Engineering Productivity? How do we fare? What can we do to improve it?
Well, if your boss’s name is not Elon Musk or if you do not work for Twitter, you can still be saved. Go on and read through. I know it is a long read.
What is Engineering Productivity?
As with anything you’re trying to improve, it starts with measuring the right data. So, you can actually track the right metrics. This data will form the basis of your analysis and baseline. I strongly recommend you don’t change anything about your current engineering process before you can collect sex weeks’ worth of data about your processes. If you start working on processes, you could end up with a Survivorship Basis.
You should have sufficient historical data to make comparisons. On top of that, most teams work in sprints of two weeks, so six weeks of data allows you to collect data for at least three different sprints. This will give you the allowances for any spikes and eliminate any unusual stress or slack on the execution.
Next, you should make gradual changes to the engineering process to see what improves or impedes the value delivery. It’s ideal to only implement one change at a time, so you can see the effect of each change, with all other things being equal. (it never is :D)
For example, if your engineering squads suffer from significant technical debt, you may want to build an additional stub related to feature completion. Every time an engineer completes a new feature, they must document the new feature. This could mean describing the feature, how is it built, what are the outcomes, how it interacts with other functions and the reasoning behind the design decisions.
By continuously measuring engineering productivity metrics, you can determine if this change has positively impacted the developers’ productivity.
How Is Engineering Productivity Measured?
There are potentially 100s of metrics you can measure for an Engineering Org. Here are four key metrics that will help you to get started with measuring engineering productivity. And I have consciously excluded the Sprint Velocity.
4 Prime Directives of Engineering Metrics
1. The One Metrics to rule them all metrics – Cycle Time
Software development cycle time measures the amount of time from work started to work delivered. It is a metric “borrowed” from lean manufacturing, and it is one of the most important metrics for software development teams. In plain speak, cycle time measures the amount of time from the first commit to production release.
2. The Oracle of an Engineering Leader – Release Frequency
You should measure how often you deploy new changes to your customers (production). In addition, you can track deployments to various branches/instances, such as feature branches, hotfix branches, or QA branches. This data would show you how long it takes for a feature/fix to move through the different development stages. In addition, the Release Frequency reflects the throughput of your team. It’s a good stand-in replacement for Agile Velocity, so you don’t spook your Engineers and you are not blind as well.
3. The Guardrail – Number of Bugs
You should definitely track the number of bugs that your team has to resolve within 2 sprints of releasing a feature. This metric helps you to understand the quality of your code better. Higher-quality code should display fewer bugs after feature deployment.
While there are derivative and more evolved metrics like Defect Density, Mean Time to Detect (MTtD), Mean Time to Resolve (MTrR) and Code coverage, those onces makes sense after you’ve taken stock of and address the prime metric “ No: of Bugs” first.
If you want a more detailed list, methodology of QA metrics, refer the links given below.
4. What is your “Blocker” – Review to Merge Time (RTMT)
This may look like a zoom-in on “Cycle time” metric we discussed earlier. But, in fact it is very different. In fact, it is an interesting metric suggested by GitLab’s development handbook.
You should measure the time between asking for a pull request (PR) review and merging the PR. Ideally, you want to reduce the time a feature spends in the review state (or pending review state). A high RTMT prevents developers from progressing while they wait for feedback and encourages context-switching between different issues/features.
Arguably, Context-Switching is the highest productivity killer and should be avoided as much as possible.
So, why would you measure all these engineering productivity metrics?
Why Is Measuring Engineering Productivity Important?
When you’re a “fast-growing startup”, it’s important to keep an eye on engineering productivity. It happens that these startups favour growth through feature delivery at the cost of effectively scaling the engineering team and ensuring the team’s efficiency.
I hear your question.
But, why does my CEO/VP/MD not understand?
Answer is simple
Assume you have to manage multiple VP’s expectations and outcomes (Sales, Marketing, Support etc), Company’s OKRs, and investors (or) board, will you have more time to dedicate to Engineering Productivity?
In these cases, technical debt can quickly grow, which will slowly kill your team’s productivity. Technical debt can have many negative consequences:
More bugs for your team to fix
Lower code quality—not only bugs but also worse code design
Harder to debug code
Scalability issues
A decline in overall happiness and job satisfaction
To avoid all of these scenarios, you should measure the engineering team’s efficiency and avoid technical debt buildup. Avoiding these problems before they occur is an excellent Occam’s razor. But addressing them head-on will have a significant impact on your organisation, both materially and culturally.
In addition to preventing your team’s productivity from going down, the engineering productivity approach allows you to experiment with various approaches to try and improve throughput & efficiency.
So, the goal is to improve the engineering process itself. For example, introducing new tools or applying new techniques. Next, you can measure the impact of these changes on your team’s productivity.
In the next part, I will write down on how can measurement improve engineering productivity, Stay Tuned!
This post is a summary of a series of “Mentoring” and “Advisory” calls I did with some early stage startups, over the past 6 months. Most of the time, one of the founder ideates, one builds/leads the build. But, they want to go fast and think they need a Product Manager. Unfortunately, most of them don’t need a Product Manager. If you are at a similar juncture, read on to find out more..
The title is a controversial question, I know!
The State of Product Management:
Off lately, Product Managers have to wear too many hats, leaving the role vague and blurring the boundaries of their area of responsibility. This ultimately leads to diminishing the value of the product manager’s core functions. Product Management is a strategic, cross-functional, front-line role that brings great value to the product and business.
But, it commonly gets abused by many fast-paced organisations expecting product managers to fill in the gaps in various disciplines. This may be process, pricing, unit-economics, partnerships, product-marketing to name a few. They can definitely do that due to their broad professional background.
Admittedly, product managers do have a broad background, otherwise they would have a hard time to be able to effectively collaborate with the stakeholders, lead the product and make the informed decisions. But this definitely should not end up with the product managers becoming de-facto “deciders” or “doers” originally intended to be done by other roles in other functions.
How do you decide if you need a Product Manager or Not?
Like any problem, there are two approaches, if an intellectual debate is more to your taste, continue reading on. If it is more of a rational “doer” approach, head straight down to it.
Intellectual Approach
Ask yourselves some questions:
If you are a founder or a leader or a decision maker, before hiring a Product Manager, question yourself as to your expectations from the product manager.
Think hard on what you want them to do:
What do you want your new product manager to change/fix in your organization? What is it that you are unable to do?
Do you not already have the in-house expertise that would help you address the current issues?
If you are still unsure about whether or not you need a product manager “in the house”,
I recommend that you go through this checklist and answer Yes/No to each of its questions:
Do you have a vision for your product? Do you believe it is aligned with the market needs?
Are you sure you are building the right product — the one that delivers value to your target audience?
Do you have a direction for your product? A long-term and a short-term roadmap?
Till now, have you been able to execute your roadmap without major distractions?
Are you capable of maintaining the strategic focus across all levels of the organization?
Do you know your competitors and what they have on the game? Proposition, not features.
Do you have an established feedback loop with your clients? (Not the feature request types)
Do you mostly base your decisions on evidence/data?
Do you find it easy to say “No” to various stakeholders from various functions while hearing their “suggestions” and “inputs” and explain them why what they think is not the “most” right thing?
If you answered “No” to more than 4 questions, you probably need a Product Manager, No doubt in that.
But the reality is, that hiring a highly capable Product Manager won’t magically change the DNA of your organisation. I have seen multiple orgs regress into a worser situation than before. Because, the person responsibl has delegated the product decisions to that Product manager with a shiny belt, without enabling/empowering him/her.
The result
Rational Approach
If you’re a CEO, founder, or senior leader considering hiring a PM, check this list and see if you need one. Lets play a guess and eliminate game.
If you can see your organisation is reflected in this article, don’t bother hiring a PM — save some money and hire a cheaper role. You would also spare a PM some misery.
Don’t bother hiring a PM…
If you have a fixed idea of what to build
You already know what you want to build, you just need somebody to build it. You’ve hired some engineers. You need somebody to gather the requirements from you and the team, and maybe manage the back-and-forth of different requirements from many stakeholders. This person then passes the requirements along to the engineers and makes sure they deliver on time.
You need a Project Manager, not a Product Manager.
If your Sales team or clients are dictating what to build
You have a handful of big clients and you’re ready to bend over backwards to deliver what they need, including building custom features. Your Sales team knows best what to build, surely, as they’re the ones talking to the customers all the time. Now it’s just a matter of writing the stories and prioritising them.
You need a Delivery Manager, not a Product Manager
If they won’t have access to your customers
You have some very-important-people as customers and their time is precious. You don’t want the new person you just hired to talk to them directly — may be they will say something untoward?
I don’t know what you need, but you certainly don’t need a Product Manager.
If you’re not ready to delegate authority
You know that product managers should be given a problem to solve, not a feature to build. Heck, you were probably a Product person yourself, who has now set up your own startup. You have the vision and the strategy and you know exactly how to get there…
What’s left for the Product Managers to do, then? Maybe hire an Engineering Manager or a Tech Lead?
If you see technology as a support function
An easy way to assess this: How much of your company budget is dedicated for product/technology/innovation? If you’re not willing to invest significant resources to staff the product/technology team properly, they’ll be left firefighting all year long.
Don’t hire a Product Manager — yet. Assess how you see technology plays a role in your company’s vision. Set aside a proper budget, hire a strong CTO or CPO, and let them build their team. Only do that if you’re willing to listen to them though — or don’t bother doing it at all.
In Sum and summary, Hire a Product Manager only if you believe you can delegate authority, and can come to a rational decision based on data. If not, hire a Project Manager, Engineering Manager or any of the other roles.
Engineering Leadership in Start-Ups: Engineering Manager, Director, VP of Engineering.
This post is partly the result of my discussions with our People practice leader and talent acquisition executive. ITILITE is at a phase of growth, where are looking for more engineering & product management bandwidth. And I had to think hard to write the various Job-Descriptions. So, I have tried to generalise it using my experiences from the last 2-3 stints. In case you’re interested to explore an Engineering Management role with ITILITE, please get in touch with me or write to careers{at}itilite.com
Engineering Leadership
As apps are becoming increasingly omnipresent and in most cases, there is a startup behind them. Engineers make up to 70% of a tech startup’s workforce, there is an increasing need for managers who look after those developers. As a result, there is a rise in the number of engineering managers in recent years. Engineering managers are responsible for delivery teams that develop these “Apps”. The following is a very generalised version of what you could do in these roles and a possible career progression.
Engineer to Tech Lead/Lead Developer
The first step in your journey from an Individual Contributor(IC) to a management role. This could be a mix of people management, delivery management, process management etc, depending on the context of your organisation. In most organisations, it is a “technical mentorship” role with some aspects of people management, quality and delivery ownership.
Most Tech Leads are natural technical leaders. They are great engineers on their own, they were well respected by the engineers around them, they worked reasonably well with the team, they understood how the product/module was designed, built and shipped, they had a decent sense for making the right kinds of product tradeoffs and they were willing to do just enough project management and people development to keep the team/project humming along.
In this role,
Most TLs would retain some independent deliverables in addition to anchoring and owning the deliveries of their team.
Most of the team still works on the same module/feature or sub-system
They do code & design reviews, suggest changes and have the final say for their modules.
Together with the Product Managers, they “own” the feature/module.
The next step in the Engineering Manager. In this role, you will be “Managing” a collection of inter-related modules/projects. In this role, the focus on timely delivery, people management and quality are higher than technical design & architecture. But, you are very much an Engineer and may be required to occasionally write quick hacks, frameworks for your developers to build atop.
The main difference is you will be responsible for the delivery of multiple projects in a related area. You will be expected to optimise the resources (Devs, Testers, etc.) available with you to maximise the outputs of your group, across multiple projects/modules
In this role, you’d be
Expected to actively engage with the Product Management teams to define what needs to be built
Defining how you will measure the outcomes of what your team is building and quantify the outcomes with metrics
Ensuring quality, getting stakeholder alignment and signoffs
Macromanage the overall deliverables of your group
The Pivot – Tech, Product, Solution Architect
The next step in your career gives you two options. One with people management, P&L accountability and other a purely technical role. If you’re planning for a pureplay technical role, some organisations have Staff Engineer, Principal Engineer etc. In essence, they are mostly a combination of Tech Lead+Architect type roles. Depending on your seniority/tenure and organisational context, you may be reporting to an Engineering/Delivery Manager, Director/VPor the CTO. In this rolw,
You will work closely with Engineering Managers, Quality Assurance leads/managers and Product Owners to design the system architecture, define the performance baselines
You will work with Tech Leads and Sr.Devs to drive the performance, redundancy, scalability among other stuff.
You will be called into discussions/decide when the team can’t reach consensus on engineering choices
Engineering Manager to Director of Engineering
A Director of Engineering role is completely different. You now have multiple leads+managers, likely multiple projects within a general focus area of the organisation. This will mean there will be way more individual deliverables and project milestones than you can track in detail on a regular basis. Now you have to manage both people and projects “from the outside” rather than “from the inside”. You’ll likely start appreciating the metrics and dashboards, as they will help you in tracking those multiple projects and deadlines, schedules, overruns etc.
You have to make sure that your managers and leads are managing their resources appropriately and support them in their effort rather than managing individual contributors and projects directly.
Lots of great technical leaders have difficulty making this transition.
While being an engineering lead/manager is certainly managing, it’s type of managing from “within the project” is much easier than “managing from outside the project” and as a director, you almost always have to manage multiple people and projects “from the outside”.
Also, as a director, you will be responsible for a number of aspects of the culture, such us
What kind of people are you hiring, setting responsibilities and workload expectations,
What is the team(s) doing for fun, how do they interact with other functions
What kinds of performance is rewarded/encouraged vs punished/discouraged.
Now, moving to some serious responsibilities, you may be the first major line of responsibility for what to do when things does not work,
an employee not working out,
a project falling behind,
a project not meeting it’s objectives,
hiring not happening in time, etc…
While most of these things are the direct responsibility of the engineering manager, the engineering manager is usually not left to face these issues alone, they work on it with the director and the director is expected to guide the process to the right decision/outcome.
I’ve seen people who were great technical leaders and good engineering managers who did not enjoy being a director at all (or weren’t as good at it) because it was a whole different type of managing bordering the administration.
Director to Vice-President
The VP of Engineering is the executive responsible for all of engineering. Development, Quality, DevOps and partly to Security and Product Management as well. While both the engineering manager and director of engineering have managers who themselves have likely been engineering managers and directors before, the VP may work for the CEO (in an early stage Startup or a smaller company) who has never been a VP of Engineering before.
A large company may have multiple levels of VPs, but in most cases, you work for someone who hasn’t been a VP of Engineering or doesn’t actually know how to do your job. This means, there simply is no first-hand experience from your Manager, that you can rely on to solve your problem. The first time you step into that role and realize that, it’s a sobering thought. You’re a pretty much on your own to figure things out. Not only are you completely responsible for everything that happens in the engineering organization, but when things aren’t going right, there’s pretty much no help from anywhere else. You and your team have to figure it out by yourselves. Many successful VPs eventually come to like this autonomy, but it can be a big adjustment when moving from director to VP.
At the director level, you can always go to your VP for help and consulting on difficult issues and they can and should help you a lot. At the VP level, you may consult with the executive team or the CEO on some big decisions, but you’re more likely talking to them about larger tradeoffs that affect other parts of the company, not how you solve issues within your team.
As a VP, you are primarily responsible for setting up processes and procedures for your organization to make it productive:
Team/Project tools such as bug system, project tracking, source code management, versioning, build system, etc.
Defining/improving processes to track, monitor and report on projects.
Defining processes to deal with projects that run into trouble.
Hiring: How you hire? What kind of people do you hire? how do you maintain the quality of new hire?
Firing: When someone isn’t working out, how do you fix it: reassignment, training, performance plan, transfer, firing?
Training: How does your team get the training they might need, it could be hard-skills, soft-skills or managerial
Rewards: How do you reward your top individual contributors and for your top managers?
You may be part of the Leadership “Council” or participate regularly in business discussions that may or may not concern your department directly. In a startup, you are often “the” technical representative on exec staff. You help craft the strategy of the business. You are relied upon for technical direction of the company (sometimes with the help of a CTO).
As a VP, you are expected to understand many important aspects of other departments, what is important to other departments and how your department serves or interacts with or depends upon other departments. Two classic example might be,
Sales depending upon certain product features/capabilities being delivered in a given timeframe to be able to convert a prospect.
Customer success depending upon certain product fixes being delivered in a given timeframe.
As a VP, you will participate in the setting of these timeframes and balancing these against all the other things your department is being tasked to do.
—
As you can see, Engineering Management/Leadership is a very interesting career option. We have multiple opening across Product and Engineering functions at ITILITE. Please see if any of these roles interest you.
