A little while ago, I wrote a thing about the Full Stack Project Manager. If you have a chance, please go read it!

I've been playing around with this idea for awhile now, and realize that it's a bit limited to restrict this to project management. I always advocated strongly for the people side of a project, and that's because I have a background in user-centred design, client service, and user experience, where the individual is elevated out of vague, generic buckets and given some agency. People are individual contributors, not "resources"; schedules are influenced by what's happening within the team, not by an inflexible work breakdown built 3 months before the project even started. It's one of the reasons I moved into a people management role – I placed a lot of importance on the building and fostering of empathy.

Full stack management is the evolution of this. A full stack manager has a skill set that allows her to understand how the pieces of her team work. She's highly technical, with a deep background in design and communication, and can critically look at the work her team is doing as part of the larger organization. She can also look up the stack, thinking strategically about her team, and how to best shepherd it through the organization.

So, what is the full stack when it comes to management? It's likely that if you're reading this, you already know about full stack development, either from your own experience, or through talking to your team. However, in case you haven't, here's a brief rundown of what the stack – and a full stack developer – is.

When developing an application, you do so considering all aspects of that application: the operating system you are developing on, the language you write the code in, the web server executing your scripts (if a web application), the file system or database storing any data your application needs, etc. In the case of a website or web application, it goes right up to the browser the person using your application has installed. This collection of technologies is colloquially known as "the stack".

Traditionally, development has been broken down into many different – and separate – areas. In the application development world, there are application developers, developers who write tests, interface developers, database developers – the list goes on. It's much the same on the web; there are front-end developers, backend developers, and developers who focus primarily on database interactions. Under most software development methodologies, such as ITIL or SDLC, developers create code then hand it off to another department for deployment or implementation by dedicated operations or systems administration staff. There are walls between these functions, and communication is often difficult between them.

Then, around about 2012, emerged the full stack developer, made popular by companies such as FaceBook. The term originated in software development circles, to describe a developer that wasn't satisfied being involved in their own walled garden. Full stack developers become involved with the full technology stack, from the operating system to the user's browser. They influence architectural decisions such as database choice, methods of deployment, version control, and application scaling. This often makes their applications more effective, because they have a greater understanding outside of their own code as to how any given application works in the real world, and can start proactively identifying and mitigating issues.

There are stacks in the management world as well. However, instead of mapping to technologies, they map to functions and processes. Here's the stack for a typical web-based team:

• Research
• Usability study / UX (User eXperience)
• Feasibility
• Marketing Requirements
• User Requirements
• Proposal / Approval
• Technical requirements
• Server acquisition
• Software design documentation
• Content strategy
• Information architecture
• Application Development
• Content development
• Interface & graphic design
• Documentation
• Building
• Production Deployment
• Quality Assurance
• User acceptance testing
• Marketing material
• Release

Some of these elements may be new or unfamiliar to you, but I guarantee they are a part of your team's work. Likely, a developer, designer, or content author are covering these for you, and including it in a more generic description of their work.

A full stack manager should be able to critically look at each of these element in order to best manage her project, however. She should be familiar with the techniques and technologies employed within each layer of the stack, and be able to critically approach any of them when needed. How else do you identify and mitigate risk within your team's work if you cannot shine a light into all of the deep, dark places within it? A full stack manager must be able to determine, for example, if a scripted build is appropriate for their project, or a full blown continuous integration environment is required to satisfy the project's objectives and, more importantly, be able to justify this choice to both the project's stakeholders and its technical staff.

She should be as comfortable determining whether continuous integration is appropriate for her project as she is building a work breakdown.

A few years ago, it was reasonable to approach a new web project and know that all you needed was a designer, a coder, and a server to host it on. For an application, you needed some coders, some testers (maybe), and some salespeople.

Now, this is no longer the case. Applications - particularly web applications - are significantly more complex than they were in the past. A typical application now involves some or all of the following:

As a manager, you can no longer be content with just managing the people and resources. To do an effective job, you need to be able to critically approach each of these facets of the project, and be prepared to act as an arbiter for them. A full stack manager should be able to look critically at the platform choice, for example, and determine whether it is in the best interest of the project, or whether that decision is being brought forward because it's what the developer is comfortable with.

As an example, I was included in a project a couple of years ago to build an API for the client's main website. There were two central requirements for the API: it had to be fast, and it had to work with JQuery. The primary developer had already built an API a few years back for a different part of the website, that was built primarily to be invoked through a server-side PHP script. The new API functionality could have been bolted on to the existing API; however, there were a number of good reasons to start from scratch.

I had sufficient technical knowledge to critically approach the existing API, so I knew that it was a non-starter in meeting the project's requirements. First, it used a very brittle method for retrieving data, which relied on an equally brittle database setup, that required any client-side code to have a robust knowledge of the data structure. The developer was comfortable with XML, so the API returned data only in a custom XML document. The developer had great justifications at hand for this choice, but ultimately, the core reason was that she was familiar with it, and hadn't really paid attention to what had been going on with client-side JavaScript over the previous 5 years.

As a full stack manager, I could look through the developer's rationalizations, and push for building a new version of the API, specific to the functionality we needed for the main website, that made use of JSON for returning data, instead of XML. This had a number of advantages: it created smaller data packets (roughly 20% less data usage than the same data in XML format), which increased performance; however, it also provided the data in a format that is native to JavaScript, which meant there was less coding required to unpack the data in the client-side code. This also improved performance over using XML and reduced the maintenance debt the extra client-side code would incur from having to unpack and manage XML data in JavaScript. Had I not had the background knowledgeable as full stack manager, I would have relied on the advice given to me by the developer and built a less efficient, less performant product.

What a full stack manager is not.

A full stack manager is not a dictator, or a micromanager. The intention behind the full stack manager movement is not to lord over your team, examining and questioning every decision, or driving the technical agenda to ensure your solution is implemented. These are solid ways to ensure failure of the team dynamic and lose the respect of your team.

If you find yourself doing this, stop for a moment and examine your situation. What led you to stepping in?

James Everingham writes about quantum team management [http://firstround.com/review/the-principles-of-quantum-team-management/] as a practice similar to full stack management. In that article, he discusses building a system with "few dependencies, single owners, [and] minimal decision points." He argues that the combined intelligence of the team is more effective at proposing and implementing solutions to any given problem, and that the key to being a good manager is to "enable as many paths forward as possible for as long as possible." However, he also writes that sometimes a manager needs to influence the team by dropping breadcrumbs to help them work through a particularly difficult problem.

This describes well how you should interact with the team as a full stack manager. You should not be using your knowledge and experience to pull the team in a given direction. Rather, you should be using your knowledge and experience to subtly nudge them when trouble strikes.

Projects are healthy and successful because the team itself is healthy, and able to work collaboratively with one another. A full stack manager earns the respect of their team because they can demonstrate adequate technical aptitude to their team.