The ultimate software development tool

Best practices on project management, issue tracking and support

Month: June 2019

Direction-Autonomy Model

Management is not about being in charge.

We usually associate the term “manager” with people managers. At first glance, a people manager’s job consists of bossing people around – telling them what to do. For example, engineering managers no longer write much code, but rather focus on organizing teams.

But a typical engineering team has a second manager – a product manager. The PM typically lacks formal authority. They are responsible for defining some work that should be done, but can’t actually tell anyone what to do or how to do it.

And yet, the PM is still a manager.

The responsibility of management is not simply making decisions and then passing them on to someone else for execution. The responsibility of management is to create an environment in which decisions can be made and work can happen. A manager does not need hiring and firing authority in order to do that. In fact, John Cutler’s litmus test for what makes a good manager is precisely the reverse – to ask “if your team could choose whether or not to hire you, would they?”

Dimensions of Decision-Making

And yet, the PM needs to make decisions. What’s more, those decisions need to stick. Nothing undermines team confidence like flip-flopping between ideas and making it impossible to plan ahead. This is the real value that a manager provides to the team – the ability to set the course and keep it steady, guiding efforts towards some useful outcome.

But it would be a mistake to model this on one axis, with decisiveness on one side and indecisiveness on the other. There are two components that contribute to the “stickiness” of a decision – direction, and autonomy.

direction autonomy quadrant


Imagine your typical product manager. Let’s call them Pip. Pip’s day-to-day involves communicating with the business to keep tabs on the strategy and metrics handed down from more senior management. Pip also takes requests coming in from other stakeholders. Before asking the team to start working, Pip will usually take some time to understand the problems more deeply and figure out what a solution might look like. The fidelity of that solution – informed by Pip’s understanding of the problem and ability to define how to address it – represents the magnitude of the direction that Pip is providing to the team.

Thus, direction flows from the organization, through Pip, into the team. If Pip is providing a low magnitude of direction, they might be creating open-ended backlog tickets, or asking to improve product-level metrics that could be raised through many different kinds of intervention. If Pip is providing a high magnitude of direction, they would write highly detailed specifications and measure success through very specific, feature- or screen-level metrics.


If direction is the fidelity of Pip’s requests to the team, autonomy represents the extent to which the team feels empowered to define their own work. A highly autonomous team can challenge Pip’s requirements and understanding of the problem. A team with low autonomy is compelled to deliver only solutions that the PM has already defined.

Autonomy is a function of the balance between Pip’s team-facing influence and org-facing influence. If Pip’s ability to influence the organization is low, all they can do is take orders from more influential colleagues, and try to fulfill them. If Pip is influential in the organization and can manage stakeholders effectively, they can give the team a high level of autonomy. If Pip trusts in the technical and problem-solving expertise of their team, they can provide air cover against the rest of the org, while the team investigates the problem and potential solutions.

The Four Quadrants

The combination of these two dimensions gives us four possible operating modes.

A skilled PM knows how to shift between them to achieve the current most important goal efficiently. However, each operating mode has a failure mode associated with it, where autonomy and direction are not sufficiently balanced, and the team’s decision-making ability breaks down.


A team is operating in the first quadrant if they have no external direction, and no autonomy. All they can do is dither aimlessly. Without either a solid direction to follow or the autonomy to find some way forward themselves, the team has no way to make progress on goals because they don’t have any stable goals in the first place. This usually happens when business leadership has failed to adequately set product goals.

direction autonomy quadrant dithering

Like the rest of the team, the PM is not contributing a lot to the organization. Pip spends most of their time copying stakeholder requests from emails to tickets. Priority can change at any time, so Pip can’t commit to studying the problem in more detail. Without a good understanding of long-term goals, and lacking any success metrics, Pip’s only real option is to double down on output. Melissa Perri outlines in detail how to escape this “build trap.”

Pip might be stuck in this quadrant if they or their management are afraid of risk. Risk-reducing strategies are key to moving away from this mode of work; teams should focus on increasing the frequency with which they ship, reducing the scope of each release, and gathering metrics from each iteration. If a release fails to deliver on the desired metrics, it’s not a failure, but a sign to try something else. Releases should be treated as experiments, and an experiment can never fail – it merely produces a negative result, which still contributes to the team’s understanding of the problem space.


If the org is willing to take some risks, Pip can start placing bets on which solutions might make an impact on important problems. If Pip has not secured much autonomy for the team, but is able to give a high magnitude of direction, it’s easy to make a decision and then stick to it. There is only once decider. The team focused on delivering to the provided specifications without being encouraged to push back or question the effectiveness of the prescribed solution.

direction autonomy quadrant discovery

This mode of delivery can work if the team is tackling a well-understood problem. If Pip has the necessary domain knowledge, or has help from outside the team, the engineering team will have everything they need in order to execute the plan. This is the working mode most commonly associated with waterfall delivery models, as well as Scrum. If the business relies on consultants and agencies, or is structured around domain-specific silos, this may be the only choice they have.

The results of working this way hinge entirely on how well the problem was actually understood. Often, the answer is “not as well as you thought”. If the team has sufficient autonomy to pivot away from the prescribed solution, they can still deliver some value, regroup, and save the day. It pays to give the experts room to reach the right outcomes, rather than over-prescribe outputs.

But if the PM has not given the team any autonomy at all, and turned them into nothing more than pixel-pushers, then there is no way to alter course. This mode of delivery becomes nothing more than ruinous micro-management. By trusting the specs more than the team, the PM dooms the entire project to failure.


PMs often try to avoid the above outcome by making a really, really good plan. A perfect plan that will anticipate every problem. But “perfect” is the worst enemy of “good enough” – and so the chase for the perfect plan usually proves futile. Not in the least, this is because a perfect plan has to involve a very low-level definition of what needs to be built, and few product managers are interested in, or capable of, getting that technical. PMs trying to anticipate risks are better off working with the engineering team and leveraging their technical expertise.

direction autonomy quadrant direction divergence

If Pip trusts the team to design a good solution, they only need to provide a small amount of direction. As long as the team understands the objectives of the project, they will be sufficiently empowered to explore many possible options, and iterate towards an outcome that moves the needle in the right direction. This is the mode you would expect to see in Lean teams, or cross-functional teams that have their own embedded designers, user researchers, and so on.

Because this mode of working has very high uncertainty associated with it, Pip needs to give the team a tremendous amount of air cover. If Pip can’t convince stakeholders that research is necessary in order to ultimately deliver better quality outputs, it can spell trouble for the team’s reputation. And without a certain amount of guidance from Pip, the team’s efforts will spin out of alignment and cease to make progress towards the end goal. Frequent iteration and a laser focus on learning are must-haves if you want to operate in the Discovery mode and not wipe out.


Most of the time, Pip will probably have neither the sway to run in an unconstrained Discovery mode for long, nor the time to put together a spec detailed enough to focus exclusively on Delivery. A balance between autonomy and direction will result in a synthesis of the two other modes.

direction autonomy quadrant synthesis

A team in this mode is empowered, but not autonomous. They have the strategic direction they need from Pip, and the freedom to make tactical decisions. The team has an understanding of the most important metrics that the project needs to push, and Pip has engaged the appropriate experts in order to figure out the general shape of a solution that might push those metrics most effectively. This is fairly typical of an organization where Agile is practiced correctly.

But when a strict top-down direction comes up against an empowered team driving a bottom-up initiative, the result can be simply unproductive conflict. PMs facing a deadlock between strategic and tactical needs must tread carefully, or else leave feelings hurt on all sides.

Moving between zones

As a project progresses, conditions around the team’s work will likely change. If the team has been shipping frequently and gathering user feedback, the need for discovery will progressively decrease. Deadlines will loom closer, and transitioning into a delivery-focused mode will help meet them.

But early on in a project, it will usually be more beneficial to do the opposite: secure as much autonomy as possible for the team to get a feel for the problem, explore fruitful directions for solving it, and maybe even push back against the initial definition. Cutting the period of discovery prematurely may significantly limit the impact that the ultimate output will make.

direction autonomy quadrant discovery


Pavel Samsonov is a Product Designer at Bloomberg Enterprise. Interested in collaboration between human and machine actors, Pavel is currently designing expert user experiences for Data License products across the GUI, API, and Linked Data platform.

You can connect with Pavel via Twitter:

FogBugz Rebuild Spec

Scope & Solution Summary

Product Summary

Briefly recap what the product is, focusing on what’s relevant to this change

FogBugz is an issue tracking service that simplifies the management of issues for small-medium sized software development teams.  It is primarily used by 5-50 person software development teams to keep track of Bugs and Features and aid in the management of the software development lifecycle. The product predominantly facilitates the entry, assignment, and retrieval of core objects (primarily issues).


Problem Summary

What is the problem, deficiency, or gap which will be addressed by this spec?

The product has 1.6M LOC and based on our 4-quadrant Code Value vs Complexity Analysis, much of its homegrown legacy code base is bad and unimportant code that can be simplified.  The code base has been incrementally developed over the past 17 years – and as a result – has an architecture that is outdated and limited in scale.
1-sentence Goal
Massively simplify FogBugz’s homegrown legacy code base by rebuilding using modern software development methods and a cloud-first architecture.


Solution Summary

In a nutshell, how are we solving the problem?

Replace bad and unimportant legacy code with the modern AWS cloud stack

  • Use AWS Appsync  (ITD1, ITD6) + Lambda + DynamoDB (ITD7) to anchor the service offering
  • Use S3 to host static website content (ITD2) and front with CloudFront + WAF (ITD 3) for web site hosting
  • Use AWS Elasticsearch service for case searching/filtering (ITD4)
  • Use Cognito user pools for authentication (ITD5)
  • Amazon SES with lambda triggers are used to listen to and feed the system (ITD9)
    • Cases are stored in Dynamo
    • Attachments, bodies, etc are stored in S3

Scope Details

Input Constraints

What important constraints were placed in a Prod3 or by the customer, rather than being decided by the spec author?

  • Maintain the current operations & ensure the initial version is an exact clone with modern backend
  • Full feature parity with the current product

Important Scope Items

What important items are in scope for the spec?

  • All current functionality (e.g. case creation, wiki, email, etc.)
  • Kiln integration – supported by the current product

Important Scope Exclusions

What important items are out of scope for the spec?

  • User migration
  • New functionality
  • Provisioning, monitoring, etc.

Solution Analysis

Important Topics

These are the sections in the next part of the document. Each section will have some background and narrative, and a set of Important Decisions. Think of them as the logical first-level decomposition of the problem.


Section Name
Brief Description
ArchitectureWhat AWS building blocks will be used for the rebuild?
Authentication/AccessHow should authentication and authorization be managed?
AWS InterfaceHow will the current FogBugz API be retrofitted to use the new AWS backend?
Data ModelingAre there simplifications that can be made to the underlying data model?
Email ClassificationHow can email based creation/updating of issues be supported?


Important Technical Decisions (ITDs)




ITD 1 – Use AWS Appsync as the platform for the rewrite

THE PROBLEMWhich AWS technology should anchor our rewrite?
(Decision in bold)
  1. AWS Appsync
REASONINGAppSync is a managed service supporting GraphQL while API Gateway is a managed service that allows developers to create REST APIs. While both AppSync and API Gateway are valid options, GraphQL is an improvement over REST in that reduces network communication (single vs multiple requests, the response only contains what is needed, etc.). In addition, AppSync, also simplifies code writing with its schema based Dynamo table generators and resolver processing logic that can replace much of the custom and proprietary validation code that is currently in place.
ADDITIONAL NOTESPlease note that RESTful APIs that are currently in place will have to be converted to GraphQL (ITD 6).


ITD 2 – Host UI static assets on Amazon S3 and use S3 to deliver the web application to the users

THE PROBLEMHow should the UI be hosted?
(Decision in bold)
  1. Host UI static assets on Amazon S3 and use S3 to deliver the web application to the users
  2. Use an Nginx/Apache/Spring-boot/other web servers
REASONINGAs FogBugz functionality will be handled by Appsync we can simply configure an S3 Bucket for static website Hosting and eliminate the additional complexity that may be associated with deploying an actual web server.
ADDITIONAL NOTESPlease note that In the context of AWS S3, a static website means a website using pure frontend technologies (HTML/CSS/JS), with the ’static’ word  referring to the static files (e.g. flat files or images) that are returned directly from the S3 bucket to the browser without being processed by any backend server.


ITD 3 – Front the S3 based static assets with CloudFront + WAF

THE PROBLEMHow should the static content be served?
(Decision in bold)
  1. Directly from the S3 bucket
  2. Front the S3 based static assets with CloudFront + WAF
REASONINGUsing CloudFront (AWS CDN) to cache and serve content improves performance by providing content closer to where viewers are located. CloudFront integrates with WAF, a web application firewall that helps protect web applications from common web exploits. WAF lets you control access to your content, based on conditions that you specify, such as IP addresses or the query string value on a content request. CloudFront then responds with either the requested content, if the conditions are met, or with an HTTP 403 status code (Forbidden).
ADDITIONAL NOTESHere is an example of how the specified AWS components can be used to serve content in a secure manner.

Elasticsearch is currently used to speed up searching capability. AWS has an Elasticsearch service offering that is easy to keep in sync with a DynamoDB using lambda functions.

ITD 4 – Use a RESTful endpoint to access AWS Elasticsearch service for search
THE PROBLEMHow should the AWS Elasticsearch instance be accessed by the UI?
(Decision in bold)
  1. Use a RESTful Appsync endpoint
  2. Use a GraphQL Appsync endpoint
REASONINGWhile GraphQL has a native Elasticsearch resolver, Option 1 is nonetheless our chosen approach as internal benchmark testing showed the GraphQL resolver to be slower than its RESTful counterpart. This decision can be easily revisited and modified in the future.
ADDITIONAL NOTESPlease note that as shown in the example below, a Route53/CloudFront combination allows a browser to fetch everything it needs from a single server (GraphQL and RESTful endpoints as well as HTML content).


Use Case
public/static content from
graphQL queries/mutations/subscriptions
static but non-public content with fine-grained lambda backed auth checks
Elasticsearch REST endpoints
Parts of dashboards via QuickSight (e.g. iframe)




Currently, FogBugz has its own username:password authentication mechanism

ITD 5 – Use AWS Cognito user pools to provide identity and access tokens

THE PROBLEMHow should users be authenticated using this backend?
(Decision in bold)
  1. Use AWS Cognito user pools to provide identity and access tokens
  2. Use Auth0 based JWT tokens
REASONINGCognito is very well integrated into the AWS ecosystem and is the natural choice for AWS based services
ADDITIONAL NOTESNote that Social login or SAML based auth (should this be introduced at some point in the future to FogBugz) can be supported as well.

Note as well that using a user migration lambda trigger approach as described to the right can enable users to keep their current passwords while still using Cognito for access to AWS AppSync and Elasticsearch

AWS Interface


The current product uses  2 UIs (new and old)

  • New – using backend RESTful APIs (Ajax)
  • Old – not using APIs

Most of the features have already been migrated to the new (ajax based) UI with only a few holdouts (e.g. pages under the account and settings section and the WIKI pages) remaining.

ITD 6 – Use GraphQL endpoints for Appsync

THE PROBLEMAppsync lets you write a REST endpoint or a GraphQL one – what is the suggested approach?
(Decision in bold)
    1. Use RESTful endpoints
    2. Use GraphQL endpoints
REASONINGImplementing the GraphQL endpoint with appsync and using the Appsync client library to replace the REST calls with the GraphQL ones is simple enough and eliminates the need to massage the JSON to suit the UI – you get back JSON the way you want it from the backend with GraphQL.
ADDITIONAL NOTESNote ITD-4 P2 feedback as well


Data Modeling

ITD 7 – Use NoSQL store (DynamoDB) to store Issues Wiki and Discussion related data

THE PROBLEMThe original FogBugz data model was relational consisting of 50 or so columns in the issue table. What kind of data model (and resultant store) should be used for the rewrite?
(Decision in bold)
  1. Dynamo (key-val)
  2. Aurora (RDBMS)
REASONINGWhile the original data model was relational – owing to the fact that the case obj has custom-fields, it is believed that this can be better modeled using NoSQL. In addition, according to AWS documentation, the Data API for Aurora Serverless is a Beta release and should only be used for testing.
ADDITIONAL NOTESAppsync works with well with Dynamo for both writing to and receiving updates from using lambda functions. DynamoDB can easily reindex an Elasticsearch instance using lambda functions and makes sure the two are always in sync. Note that receiving updates from Dynamo requires using DynamoDB streams


Email Classification

IFD 9 – Use AWS SES and lambda functions for email support

THE PROBLEMHow can the current proprietary SMTP handling be deprecated?
(Decision in bold)
  1. Use SendGrid or other email service provider
  2. Use AWS SES + lambda triggers
REASONINGSES is very well integrated into  the AWS ecosystem and is the natural choice for AWS based services